"How do I do transactions across a distributed system?" is a very common question. This talk taught the basic conceptual model, which can then be customized and applied to specific use cases and consistency requirements.
INTRO SELF / DID BOOTCAMP TRAINING / TALK YESTERDAY => 1.0 last week => COMMON QUESTION
going to show you a model for doing transactions in a distributed application, like the ones you can build with Akka .NET
high level outline here, gonna teach you the model since only have 5 minutes
no Leslie Lamport shit in here
Pebble story => AVOID DUPES, ENSURE CRITICAL OPS DONT HAVE DUPES
you can use this for many things
large batch jobs, such as crawling / scraping
THIS IS A TWO PHASE COMMIT
preparing for the transaction => can we do this?
committing the transaction => use case specific
gonna model a distributed transaction, which you’d wrap in some more retry plumbing
what is a transaction? => an atomic unit of work that can’t be divided any more, and succeeds or fails as a unit
CAP theorem
is really a tradeoff, a way of making decisions between consistency and latency
if you have super high consistency requirements, it’s doable but a longer convo
HOW WOULD YOU SCALE THIS
to scale this in production, need more plumbing around this to ensure parallelization (following a consistent hashing model similar to C*), but this is the core model
this is similar to how cassandra does it
THIS CAN SCALE OUT ACROSS MANY MACHINES USING CLUSTERING
HOW YOU DO THAT? => WE CAN SHOW YOU
ONLY HAVE TO WRITE 2 ACTORS TO DO THIS (VERY LITTLE CODE)
CAN SCALE IT OUT USING THE ACTOR SYSTEM
EVEN THO ONE TRANSACTION AT A TIME, MANY IN PARALLEL
WANT SCALABLE? GO HERE AND BOOK A TRAINING OR TALK TO ME AFTER