Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Little Important Things in Distributed Architec...

Riga Dev Day
March 13, 2016
100

Little Important Things in Distributed Architectures by Andres Jaan Tack

Riga Dev Day

March 13, 2016
Tweet

Transcript

  1. Little Important Things
 in Distributed Architectures Early decisions that help

    us delight our users. Andres Jaan Tack Riga Dev Day 2016
  2. About Me • Born around Chicago, Illinois, U.S.A. • Studied

    Computer Science
 Specialized in Operating Systems, Concurrent Systems
 University of Illinois at Urbana-Champaign, B.S.
 University of Wisconsin–Madison, M.S. (Michael Swift) • June, 2010: Moved to Estonia, joined Skype
 Developed infrastructure for Skype-to-Skype and Skype-to-PSTN call signaling.
 Participated in migrating Skype’s support infrastructure to the cloud. • April, 2015: Joined Twilio
 as a Tech Lead
  3. About Twilio • We provide cloud-based communication APIs
 We provide

    the engine,
 you provide the experience. • Developer-Focused
 Developers make business decisions; we can help! • >500 Employees worldwide • Cloud-Native, Global
 Easy to manage, pay-as-you-go, works with existing infrastructure.
  4. The distributed nature
 of our applications is
 driven by the

    features
 our customers love and demand!

  5. Features we demand: “Liveness” When the state or the data

    changes, we want to see it: • Quickly • Efficiently
 (weak wifi?) • Automatically
 (push, not pull!)
  6. Not really chat-specific. • “Notification” of new data or signals.

    • Ability to work on data offline. • Sharing your status with others. • Pushing many data through a small pipe.
  7. Data. Which is… that is concurrently represented and manipulated on

    multiple clients. VJCVCTGRTQDCDN[OQDKNG @
  8. use continuous natural numbers for ordering data. Don’t insertAt(2, )

    insertAt(2, ) insertAt(2, ) insertAt(2, ) Alex Bob insertAt(2, ) insertAt(2, ) !!
  9. use continuous natural numbers for ordering data. use them for

    gap detection, if you need to do so. Don’t ✔ Do Voilá, thing #1. Voilá, thing #3. Wait, what about #2?
  10. build total orderings. Don’t Total ordering is unnecessarily strict. 1.

    Wake up. (A beautiful new day!) 2. Turn off alarm. (Boy I’m hungry!) 3. Proceed to bathroom. (Ah come on…!) 4. Brush teeth. (So. Hungry.) 5. Take shower. (This is stupid.) 6. Get dressed. (Is soap edible?) 7. Proceed to kitchen. (Oh thank god.) 8. Eat something. (!!!) 9. Walk out front door. (Hmm, brush teeth again?)
  11. build total orderings. Don’t In Data-centric Systems, total orderings mean

    retries for no good reason. Can I be after blue? Nope, yellow was faster. Nope, red has better internet. What about after yellow? After Red? …
  12. Karl O’Livvy: Should we show them how we make the

    sausage? Michelle: Absolutely not! Inappropriate. Danielle: No! But what will I show my users?
 Graphs are too complex! Data != Representation
  13. You can always form a Total Ordering from a Partial

    Ordering! Timestamps! Random GUIDs! Karl O’Livvy: Should we show them how we make the sausage? Michelle: Absolutely not! Inappropriate. Danielle: No! 0x789 0x123 0x234 ≼ Karl O’Livvy: Should we show them how we make the sausage? Michelle: Absolutely not! Inappropriate. Danielle: No! 12:00.50 12:01.12 12:01.13 ≼
  14. ✔ Do mark things deleted. That’s information! • History of

    actions taken • Record of possible alternative intent • Opportunity to retrospectively
 re-interpret and recover.
  15. ✔ Do mark things deleted. • History of actions taken

    • Record of possible alternative intent • Opportunity to retrospectively
 re-interpret and recover. And these things generally don’t cost much!
  16. ✔ Do use natural numbers for gap detection, not data

    order. ✔ Do build partial orders, not total orders. ✔ Do mark as deleted, i.e.
 manipulate data monotonically.