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
Learning to Build Distributed Systems the Hard Way
Search
Theo Hultberg
March 05, 2013
Programming
1
140
Learning to Build Distributed Systems the Hard Way
Scandinavian Developer Conference 2013
Theo Hultberg
March 05, 2013
Tweet
Share
More Decks by Theo Hultberg
See All by Theo Hultberg
Datalakes at AWS Summit Stockholm 2018
iconara
0
73
Building a CQL driver
iconara
0
49
Chasing the Elephant
iconara
0
76
Learning to Build Distributed Systems the Hard Way
iconara
2
200
Learning to Build Distributed Systems the Hard Way
iconara
3
5.1k
Concurrency and Distributed Systems in JRuby
iconara
3
620
A Guide to the Post Relational Revolution
iconara
4
5.4k
Standing on the Shoulders of Giants with JRuby
iconara
4
150
Shortcuts Around the Mistakes I've Made Scaling MongoDB
iconara
4
160
Other Decks in Programming
See All in Programming
Long journey of Ruby standard library RubyKaigi 2024
andpad
2
500
Findy - エンジニア向け会社紹介 / Findy Letter for Engineers
findyinc
2
75k
チーム立ち上げにAWSを活用したらClaudeさんに褒められた話
mkdev10
3
230
Next.js App Router
quramy
14
2.3k
TypeScriptのパフォーマンス改善
yajihum
14
5.3k
TypeScriptで使いやすいOpenAPIの書き方
yukimochi_dwango
1
990
株式会社ゼネテック
genetec
0
130
Embedding it into Ruby code
soutaro
2
520
JS RPCを理解する
yusukebe
5
310
Upgrading Legacy to the Latest PHP Version
afilina
PRO
0
110
RaaP
ksss
0
170
TypeScriptの型とパフォーマンス (TSKaigi 2024)
ypresto
15
5.3k
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
244
12k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
67
14k
Web development in the modern age
philhawksworth
203
10k
Faster Mobile Websites
deanohume
300
30k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
245
20k
Git: the NoSQL Database
bkeepers
PRO
423
63k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
26
2.3k
Raft: Consensus for Rubyists
vanstee
133
6.3k
The Cost Of JavaScript in 2023
addyosmani
21
4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
14
8.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
126
32k
Transcript
LEARNING TO BUILD DISTRIBUTED SYSTEMS THE HARD WAY @iconara NEW
and improved!
LEARNING TO BUILD DISTRIBUTED SYSTEMS THE HARD WAY @iconara NEW
and improved!
speakerdeck.com/iconara
Theo / @iconara
chief architect at BURT
FAILURE embrace it
SCALE how hard can it be? let’s worry about that
later.
KNOW YOUR LIMITS who’s the largest customer you could sign?
what would happen if you did?
BALANCE “customer” is a really bad shard key, find something
that distributes evenly & uniformly
SCALE OUT, NOT UP bigger boxes aren’t going to save
you <
START WITH TWO OF EVERYTHING going from one to two
is the hardest, force yourself to solve the scaling problem up front
START WITH TWO OF EVERYTHING you’ll solve the scaling problem,
and need less overcapacity THREE
LIMITS we’ll probably never run out of memory
BACK PRESSURE what happens when the system is working at
full capacity? what happens next?
PRODUCTION = QA production is where the weird shit happens,
can you test production traffic without deploying to production? =
MONOLITHS running all the things on the same box is
really fast. what could ever go wrong? 1:4:9
DECOUPLE UNTIL IT BREAKS moving things to separate services means
that you will be able to scale them independently
PROCESSING & STORAGE separate processing from storage, they almost never
scale together.
SCALE exponential scaling is also scaling, but you want it
as cheaply as possible
SCALE your CFO may not agree that O(2n) = O(n)
GÖTEBORG, DISTRIBUTED @gbgdistr meetup.com/gbgdistributed
KTHXBAI @iconara github.com/iconara architecturalatrocities.com burtcorp.com