LEARNING TO BUILDDISTRIBUTED SYSTEMS

THE HARD WAY

@iconara

NEWand improved!

LEARNING TO BUILDDISTRIBUTED SYSTEMS

THE HARD WAY

@iconara

NEWand improved!

speakerdeck.com/iconara

Theo / @iconara

chief architect at BURT

FAILUREembrace it

SCALEhow hard can it be? let’s worry about that later.

KNOW YOUR LIMITSwho’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 UPbigger boxes aren’t going to save you

<

START WITH TWOOF EVERYTHINGgoing from one to two is the hardest,

force yourself to solve the scaling problem up front

START WITH TWOOF EVERYTHING

you’ll solve the scaling problem,and need less overcapacity

THREE

LIMITSwe’ll probably never run out of memory

BACK PRESSUREwhat happens when the system is working at full

capacity? what happens next?

PRODUCTION = QAproduction is where the weird shit happens,

can you test production traffic without deploying to production?

=

MONOLITHSrunning all the things on the same box is really fast.

what could ever go wrong?

1:4:9

DECOUPLEUNTIL 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.

SCALEexponential scaling is also scaling,

but you want it as cheaply as possible

SCALEyour CFO may not agree that O(2n) = O(n)

GÖTEBORG, DISTRIBUTED

@gbgdistrmeetup.com/gbgdistributed

KTHXBAI@iconara

github.com/iconaraarchitecturalatrocities.com

burtcorp.com