SWIMming in the Microservices Ocean
summary
Describes concrete pieces: adoption of the SWIM gossip membership protocol, consistent hashing for application‑level sharding, and Uber’s move from HTTP to TChannel plus Hyperbahn for overlay networking. Claims app‑level sharding gives predictable routing so a lookup hits the owner max in three hops, handles millions of events, and keeps state in the service instead of a central store. Recommends Zipkin for distributed tracing and shows these components actually running in production.
AI-written summary · about
chapters (18)
- 0:00Start
- 5:26Coordination?
- 9:54No RESILIENCY No Fault Tolerance
- 10:49State of the cluster
- 12:34Failure detection
- 13:14Information dissemination
- 13:47Equal distribution of the workload
- 14:04Born for Distributed Systems
- 14:23Adding a node to the cluster
- 14:48How to rebalance the topology?
- 15:04Consistent Hashring
- 16:22Partitioning
- 16:51Distribution of the application state
- 19:09Application Level SHARDING
- 28:37WHY RPC?
- 30:06AWS Lambda
- 30:39Serverless
- 31:35Function distribution is the future!
related talks
28mSWIMming in the microservices ocean
35mBuilding Scalable Stateful Services
59mMicroservice Swarms: Decentralized Discovery and Scaling
52mBeyond Microservices: Streams, State and Scalability
27mSolving service discovery: Node.js microservices without a registry
26mBuilding Scalable Microservice APIs From The Beginning
49mMicroservices: An unexpected Journey
24mPatterns of Evolution from Monolith to Microservices