Scalable architecture from the ground up
summary
A runnable .NET redis clone of ~200 lines hits 170,000 requests/sec on a Raspberry Pi with P99 latencies under 100ms, proving raw hardware is often irrelevant. The architecture recommendation is concrete: keep a local DB per app, put work into queues and process later so critical paths stay cheap, batch third‑party calls and monitor queue drain, and offload uploads via pre-signed S3 uploads so background workers scale independently.
AI-written summary · about
chapters (22)
- 0:00Introduction and speaker introduction
- 1:04Defining scalability and its importance
- 3:14Performance vs scalability on a Raspberry Pi
- 7:27Why throwing hardware at scalability fails
- 8:53Learning scalability from others' mistakes
- 10:38Setting measurable SLAs for scalability
- 13:30Growth pitfalls and unsustainable architectures
- 15:16Critical path and user waiting time
- 18:26Local databases and avoiding shared bottlenecks
- 20:57Moving expensive operations to background queues
- 24:11Asynchronous processing and user experience
- 27:45Queue processing and Auto Scaling differences
- 31:54Operational simplicity of queues
- 33:25Managing user-visible transformations
- 35:52Acknowledging orders without immediate fulfillment
- 37:14Stupid solutions and scalable architectures
- 38:16Example: Reimbursement system with queues
- 40:01PHP’s stateless design and scalability
- 41:25Q&A: Synchronous vs asynchronous systems
- 45:06Scalability lessons from business processes
- 47:16Avoiding unnecessary complexity in systems
- 50:07Business precision vs technical precision
related talks
53mPowering 100+ million daily users
42mPowering 100+ million daily users
47mMonolith to Microserv. at 20M+ requests per second: Latency and Scale Challenges
36mBuild a Cloud Native Asynchronous Messaging System For Scale With Redis
06mHow We Achieved 100x Scale
13mLow-Maintenance Backend Architectures for Scalable Applications
53mBuilding microservices applications with Amazon MemoryDB
40mUncoupling Systems