Digital scale-up architectural patterns
summary
Client sees 4,000% user growth and needs quick, pragmatic choices: deliberately accept technical debt by adding features into the monolith or use DB views as a temporary data store to validate product demand, then extract later; prefer simple point‑to‑point queues and default to REST/gRPC over custom binary instead of jumping to Kafka; design for data gravity and separate real‑time versus batch flows; measure success with lead time/cycle time, user impact (latency, onboarding) and engineering satisfaction to confirm architectural changes actually speed delivery.
AI-written summary · about
chapters (12)
- 0:00Intro
- 1:14Rickey Zachary
- 5:00Digital scale-ups
- 17:04Architecture scale up issues
- 21:57Bottlenecks and technical debt
- 28:37Pattern - strategic decoupling
- 31:51Pattern - optimize messaging and events
- 34:53Pattern - data movement
- 37:31Anti pattern - early Microservices
- 39:24Anti pattern - late monolith
- 40:51Anti pattern- data velocity
- 42:48Measuring improvement • Are features making it to production faster?
related talks
26mArchitecting for scale
49mHypergrowth scaling made simple
14mGrowing pains: Scaling and re-architecting systems under fire
01h 02mTools for simplified large scale systems
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
19mScaling Fast – Engineering Lessons From ~15 Years of Tech Startups
17mExtreme Engineering-Elements of Building a High -scale Broking Application- 19mScaling Fast – Engineering Lessons From ~15 Years of Tech Startups