Pros/Cons of Highly Scalable Microservice Systems
summary
Panelists argue most projects never need global scale and advise first asking whether 200,000 concurrent users is actually required; companies report a working stack with NGINX gateway and CDN, nightly instance-level performance tests, and Netflix OSS style fault injection like chaos monkey. Surprising bottlenecks include real-time stats collection and logging causing disk full cascades. Practical fixes shown are edge caching, local caches over sync calls, measuring per-instance capacity, and choosing data models that avoid expensive joins.
AI-written summary · about
chapters (26)
- 0:00Introduction
- 0:43Do you really need to scale
- 2:07Defining scale
- 2:32Scaling issues
- 4:05Performance issues
- 5:06Developer problems
- 6:30Scalability is not a problem
- 7:24Focus on the things you can directly affect
- 8:32How do you test before production
- 9:05Single common points of pressure
- 10:03Test for failures
- 11:24Assessing performance problems
- 13:51External vs internal traffic
- 14:50Most surprising scaling problem
- 16:44Biggest surprises
- 17:56granularity
- 18:23data model
- 20:12audience questions
- 20:46Cober vs Microservices
- 22:34Centralized Governance
- 23:23How many do you need
- 26:38Code
- 27:36Traps
- 29:00Moving from cellar to microservices
- 30:34Does it work for you
- 32:06Closing comments
related talks
53mHow do we build high‑load microservices
49mChallenges in Implementing Microservices
08mMicroservices at Scale
19mMicroservices vs. Monolith for Scalability and Efficiency
23mMicroservices – Diptanu Choudhury
13mYou're not Netflix (Microservices, Monolith architecture)
47mMicroservices? Monoliths? An Annoying Discussion!
48mChallenges in Implementing MicroServices