Building Scalable Orchestration
summary
Production orchestration evolves through four rewrites from a monolithic Python/C app that collapses at ~3,000 managed servers to an asynchronous, message-driven platform that scales. It switches databases after MySQL query contention to Postgres after MySQL failed for heavy workflow load, moves long-running state out of memory, and adopts 0MQ+HTTP (xiv-whiskey) for transport with pyramid and paramiko for SSH. The result is moved from monolith to async microservices and a system that benchmarks 5,000 connections per process and runs in large financial customers.
AI-written summary · about
chapters (13)
- 0:00Start
- 3:44Orchestration
- 4:10Sequencing
- 8:48First Generation (E1)
- 13:51Second Generation (E2)
- 15:55Benefits
- 17:07E2 Problems
- 19:25Third Generation (E3)
- 23:04Stack
- 24:44Managing State
- 25:58Asynchronous
- 27:23Message Passing
- 28:31E3 Problems
related talks
44mGetting started with Orchestration and Choreography in Distributed Applications
27mEmpowering Resilient Scalability: The Power of Choreography in Distributed Systems
42mOrchestration vs Choreography, A Guide To Composing Your Monolith
06mHow We Achieved 100x Scale
37mHow the hell do I run my microservices in production, and will it scale
40mDeploying node.js at scale
17mExtreme Engineering-Elements of Building a High -scale Broking Application
35mFrom Dinosaurs to Snakes - Decomposing the Enterprise Monolith