Taking Django Distributed
summary
Argues that the practical work is not the topic but the specifics: uses Channels and channel layers as an implementation for a service bus and reports Eventbrite moving to channel layers successfully, warns about replication lag ~100ms and the need for database pinning, recommends small clusters of services (about 5–10 services rather than instant microservice explosion), cites extremes like 2500 services to show failure modes, and recommends sharding only when code funnels through a single query layer.
AI-written summary · about
chapters (22)
- 0:00Intro
- 0:53Computers hate you.
- 1:39It's time to split things up a bit.
- 2:52There is no one solution
- 5:18Use apps! They're a good start!
- 6:01Formalise interfaces between apps
- 8:13How do you communicate?
- 10:19Databases
- 14:09Non-consistency is everywhere
- 16:49Load Balancing
- 17:34Different processor loads
- 19:52WEBSOCKETS
- 22:56Developers are people tool
- 23:58Technical debt can be poisonous
- 24:49Single repo? Multiple repos?
- 26:52Ownership gaps
- 28:54Don't go too micro on those services
- 30:58Communicate over a service bus
- 32:26Work out where to allow old data
- 33:43Design for future sharding
- 35:47Expect long-polls/sockets to die
- 36:36Independent, full-stack teams
related talks
01h 03mMicroservices vs The Distributed Monolith
49mChallenges in Implementing Microservices
40mService Architectures for Mere Mortals
54mServices, Services, Everywhere!
18mMicroservices: the small print
34mThe Road to a Distributed Application, or the Pitfalls of CQRS/DDD
48mChallenges in Implementing MicroServices
36mDo Proper Monoliths before You Do Microservices!