Monolith to reactive
It's all about architecture
James Roper
@jroper
Agenda
- 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
Summary
- Monolith to microservices requires rearchitecting data flows
- Failure and inconsistency must be managed
- Use:
- Circuit breakers
- Failure degradation
- Asynchronous messaging
- Denormalization