Scaling yout Architecture with Services and Events
summary
History shows monoliths morph to microservices after scale pain points such as feature velocity and database limits like the 3.4 million lines eBay monolith or needing a 72‑way machine. Practical pattern: create a service, backfill data, run dual-write and feature-flagged reads, then switch off the old DB to keep zero downtime. Use events as first‑class interfaces, serve shared data via materialized view caches or synchronous lookups, and implement cross‑service workflows with saga choreography or orchestration instead of distributed transactions.
AI-written summary · about
chapters (16)
- 0:00Intro
- 1:45Background
- 2:41Evolution to Microservices
- 8:37Microservice Architecture
- 10:48Why Migrate?
- 14:17Extracting Microservices
- 18:45System of Record
- 20:12Events are First-Class
- 21:20Microservices and Events
- 22:59Shared Data
- 26:34Joins
- 31:38Transactions
- 33:49Workflows and Sagas
- 39:31Intermediate States
- 41:30Choreography
- 43:16Orchestration
related talks
42mQ&A - Monolith to Microservices
24mPatterns of Evolution from Monolith to Microservices
54mFrom a distributed monolith to a microservices solution
42mLarge-Scale Architecture: The Unreasonable Effectiveness of Simplicity
36mDo Proper Monoliths before You Do Microservices!
43mMicroMonolith - Top anti-patterns of distributed systems
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
57mSplitting Monolith Application to Microservices