Just in Time Architecture
summary
A team moves from a monolithic server with atomic database transactions to microservices, hits real failures: customer balances are deducted but avatars are not assigned, retry storms and cascading outages due to availability coupling. Fixes include idempotent request IDs, then shifting to event-driven design using transactional outbox or transaction logs (or full event sourcing) to guarantee events, and choosing between choreography vs orchestration with orchestrators issuing commands and compensating transactions to restore consistency. Practical tradeoffs and migration costs are measured throughout.
AI-written summary · about
chapters (9)
- 0:00Just in Time Architecture intro
- 6:26Monolith challenges
- 10:00Monolith to microservices
- 13:34Distributed monolith pitfalls
- 21:18Event-driven basics
- 27:17Reliable event production
- 33:37Choreography vs orchestration
- 45:03Architecture evolution
- 48:35Closing remarks
related talks
55mJust-in-time Architecture
31mMonolith to Microservices: A Guide to Seamless Transitions
44mHighly Available, Distributed & Resilient Software... Team
25mData-Driven Migration from Monoliths to Event-Driven Microservices
23mDesigning Robust and Scalable Distributed Applications
29mApps, Stacks, and Frameworks: Avoiding “Shiny Object” Syndrome
59mSucceeding at Reactive Architecture
37mClean Architecture: Stories of Pain and Joy From the Codebase