Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Scaling Django with Distributed Systems
Search
Andrew Godwin
April 07, 2017
Programming
3
2.2k
Scaling Django with Distributed Systems
A talk I gave at PyCon Ukraine 2017.
Andrew Godwin
April 07, 2017
Tweet
Share
More Decks by Andrew Godwin
See All by Andrew Godwin
Reconciling Everything
andrewgodwin
1
310
Django Through The Years
andrewgodwin
0
200
Writing Maintainable Software At Scale
andrewgodwin
0
440
A Newcomer's Guide To Airflow's Architecture
andrewgodwin
0
350
Async, Python, and the Future
andrewgodwin
2
660
How To Break Django: With Async
andrewgodwin
1
730
Taking Django's ORM Async
andrewgodwin
0
720
The Long Road To Asynchrony
andrewgodwin
0
660
The Scientist & The Engineer
andrewgodwin
1
760
Other Decks in Programming
See All in Programming
MCPで実現できる、Webサービス利用体験について
syumai
7
2.1k
商品比較サービス「マイベスト」における パーソナライズレコメンドの第一歩
ucchiii43
0
200
코딩 에이전트 체크리스트: Claude Code ver.
nacyot
0
1k
SwiftでMCPサーバーを作ろう!
giginet
PRO
2
210
What's new in AppKit on macOS 26
1024jp
0
180
バイブコーディング超えてバイブデプロイ〜CloudflareMCPで実現する、未来のアプリケーションデリバリー〜
azukiazusa1
2
720
フロントエンドのパフォーマンスチューニング
koukimiura
6
2.3k
Google I/O Extended Incheon 2025 ~ What's new in Android development tools
pluu
1
190
The Evolution of Enterprise Java with Jakarta EE 11 and Beyond
ivargrimstad
0
520
AIコーディングエージェント全社導入とセキュリティ対策
hikaruegashira
15
8.2k
[SRE NEXT] 複雑なシステムにおけるUser Journey SLOの導入
yakenji
0
800
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
570
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Practical Orchestrator
shlominoach
189
11k
BBQ
matthewcrist
89
9.7k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
Rails Girls Zürich Keynote
gr2m
95
14k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Music & Morning Musume
bryan
46
6.7k
Transcript
None
Andrew Godwin Hi, I'm Django core developer Senior Software Engineer
at Used to complain about migrations a lot
Distributed Systems
c = 299,792,458 m/s
Early CPUs c = 60m propagation distance Clock ~2cm 5
MHz
Modern CPUs c = 10cm propagation distance 3 GHz
Distributed systems are made of independent components
They are slower and harder to write than synchronous systems
But they can be scaled up much, much further
Trade-offs
There is never a perfect solution.
Fast Good Cheap
None
Load Balancer WSGI Worker WSGI Worker WSGI Worker
Load Balancer WSGI Worker WSGI Worker WSGI Worker Cache
Load Balancer WSGI Worker WSGI Worker WSGI Worker Cache Cache
Cache
Load Balancer WSGI Worker WSGI Worker WSGI Worker Database
CAP Theorem
Partition Tolerant Consistent Available
PostgreSQL: CP Consistent everywhere Handles network latency/drops Can't write if
main server is down
Cassandra: AP Can read/write to any node Handles network latency/drops
Data can be inconsistent
It's hard to design a product that might be inconsistent
But if you take the tradeoff, scaling is easy
Otherwise, you must find other solutions
Read Replicas (often called master/slave) Load Balancer WSGI Worker WSGI
Worker WSGI Worker Replica Replica Main
Replicas scale reads forever... But writes must go to one
place
If a request writes to a table it must be
pinned there, so later reads do not get old data
When your write load is too high, you must then
shard
Vertical Sharding Users Tickets Events Payments
Horizontal Sharding Users 0 - 2 Users 3 - 5
Users 6 - 8 Users 9 - A
Both Users 0 - 2 Users 3 - 5 Users
6 - 8 Users 9 - A Events 0 - 2 Events 3 - 5 Events 6 - 8 Events 9 - A Tickets 0 - 2 Tickets 3 - 5 Tickets 6 - 8 Tickets 9 - A
Both plus caching Users 0 - 2 Users 3 -
5 Users 6 - 8 Users 9 - A Events 0 - 2 Events 3 - 5 Events 6 - 8 Events 9 - A Tickets 0 - 2 Tickets 3 - 5 Tickets 6 - 8 Tickets 9 - A User Cache Event Cache Ticket Cache
Teams have to scale too; nobody should have to understand
eveything in a big system.
Services allow complexity to be reduced - for a tradeoff
of speed
Users 0 - 2 Users 3 - 5 Users 6
- 8 Users 9 - A Events 0 - 2 Events 3 - 5 Events 6 - 8 Events 9 - A Tickets 0 - 2 Tickets 3 - 5 Tickets 6 - 8 Tickets 9 - A User Cache Event Cache Ticket Cache User Service Event Service Ticket Service
User Service Event Service Ticket Service WSGI Server
Each service is its own, smaller project, managed and scaled
separately.
But how do you communicate between them?
Service 2 Service 3 Service 1 Direct Communication
Service 2 Service 3 Service 1 Service 4 Service 5
Service 2 Service 3 Service 1 Service 4 Service 5
Service 6 Service 7 Service 8
Service 2 Service 3 Service 1 Message Bus Service 2
Service 3 Service 1
A single point of failure is not always bad -
if the alternative is multiple, fragile ones
Channels and ASGI provide a standard message bus built with
certain tradeoffs
Backing Store e.g. Redis, RabbitMQ ASGI (Channel Layer) Channels Library
Django Django Channels Project
Backing Store e.g. Redis, RabbitMQ ASGI (Channel Layer) Pure Python
Failure Mode At most once Messages either do not arrive,
or arrive once. At least once Messages arrive once, or arrive multiple times
Guarantees vs. Latency Low latency Messages arrive very quickly but
go missing more Low loss rate Messages are almost never lost but arrive slower
Queuing Type First In First Out Consistent performance for all
users First In Last Out Hides backlogs but makes them worse
Queue Sizing Finite Queues Sending can fail Infinite queues Makes
problems even worse
You must understand what you are making (This is surprisingly
uncommon)
Design as much as possible around shared-nothing
Per-machine caches On-demand thumbnailing Signed cookie sessions
Has to be shared? Try to split it
Has to be shared? Try sharding it.
Django's job is to be slowly replaced by your code
Just make sure you match the API contract of what
you're replacing!
Don't try to scale too early; you'll pick the wrong
tradeoffs.
Thanks. Andrew Godwin @andrewgodwin channels.readthedocs.io