CAPtivating architecture: Navigating Distributed Systems and Microservices
summary
Monolith splits into three services—payment, betting, RG—and experiments compare synchronous chained calls, orchestrated HTTP flows, choreography Sagas and an orchestrated Saga over a message broker; the orchestrated Saga runs via a broker with the payment service as orchestrator/participant and gained 17 hours of uptime annually versus direct sync calls. Real findings: a study shows 31% missing timeout and 47% misconfigured timeouts; production rule is use the 99th percentile read timeout, idempotency via request fingerprinting or client request IDs, and backoff, jitter and circuit breakers.
AI-written summary · about
chapters (17)
- 0:00Distributed systems challenges
- 1:09Player account management case
- 5:06Microservice splitting issues
- 7:56Bounded contexts design
- 9:00CAP theorem trade-offs
- 10:24Betting flow choreography
- 13:19Complex flows orchestration
- 16:35Deposit flow orchestration
- 18:22Saga pattern for transactions
- 21:58Choreography vs orchestration
- 26:59Timeout and retry policies
- 29:16Timeout impact on stability
- 32:05Optimal timeout calculation
- 35:18Idempotency and retries
- 38:49Resilience strategies
- 39:11Microservice adoption readiness
- 39:52Closing remarks
related talks
27mBuilding Microservices Architecture The Right Way based on Saga Pattern
01h 07mChallenges of microservices Distribution Systems
58mElements of Distributed Architectures
59mGranularity & Communication for Microservice Architectures
01h 03mMicroservices vs The Distributed Monolith
46mGranularity & Communication for Microservices Architectures
24mPatterns of Evolution from Monolith to Microservices
51mNot Just Events: Developing Asynchronous Microservices