Microservice Challenges
summary
Argues microservices work best when components are tiny, polyglot, and versioned — sometimes three versions running simultaneously — and contrasts synchronous request flows with an event-driven model where every event floods a common pipe. Describes rapids rivers and ponds as an architectural metaphor, warns of exploding message volume (one user can use MQ Series bandwidth up to five percent), recommends separate per-service databases, and notes functional languages like Elixir/Erlang may change how services compose.
AI-written summary · about
chapters (8)
- 0:00Microservices challenges
- 1:45Sync vs async microservices
- 3:33Rapids rivers ponds model
- 5:57Car rental event demo
- 10:48Asynchronous design challenges and benefits
- 11:29Microservices vs closure env
- 13:54Closure limits in decomposition
- 15:19FP and microservices future
related talks
48mChallenges in Implementing MicroServices
38mMicroservices, a bittersweet symphony
49mChallenges in Implementing Microservices
50mChallenges in Implementing Microservices
54mThe Long Sad History of Microservices
01h 03mMicroservices vs The Distributed Monolith
26mPros/Cons of Microservices
57mEmbracing Microservices
