Monolith to reactive

It's all about architecture

James Roper



  • Identify pitfalls of monolith conversions
  • Architect reactive solutions
  • See Lagom in action
  • Live coding!

Lagom Auction

  • ebay clone
  • Was a monolith, converted to microservices
  • Will one day overtake ebay!

What if something goes wrong?

  • Microservices means more moving parts
    • More chance for failure
    • More chance for inconsistency

Synchronous communication

synchronous adj. - existing or occurring at the same time.

Synchronous communication

  • Typically request/response
    • e.g. REST
  • Both systems must be responsive at the same time

Pattern 1: Circuit breakers

  • A gate that opens in the event of failure
    • Including timeouts
  • Protects already failing services
  • Allows fail fast handling

Pattern 2: Failure recovery

  • Work around failure by degrading
  • Not every call is necessary to render every page

Failure can lead to inconsistency

Inconsistency from failure

  • Synchronous "at same time" communication of updates is dangerous
    • Transactions can't span service boundaries

Pattern 3: Asynchronous messaging

  • Does not require both systems to be responsive
  • Perfect if you already persist events
  • Use persistent events as a source of messages

Unacceptable degradation

  • Earlier we degraded the item page with empty bid history
  • Price was also $0
  • Users may tolerate no history, but not wrong price

Pattern 4: Denormalize

  • Push important information to other services
    • Important for system functions
    • Important for business functions
  • Store duplicated information in those services
    • AKA denormalization


  • Monolith to microservices requires rearchitecting data flows
  • Failure and inconsistency must be managed
  • Use:
    • Circuit breakers
    • Failure degradation
    • Asynchronous messaging
    • Denormalization

Next steps