CTO School notes 2015/5/11

Micah Lemonik
Architectural history of google docs

still three tier setup
stateful server has entire object in memory at all times

serverside calculating

transaction log (mutation log + snapshot lookaside)
communitivity of mutations – need to be able to apply mutations in different order
this made word processing a difficult problem

word:
insert “foo” @4

these actions are non-communative
server arbitrates order of mutations, must transform all deltas into idempotent actions

keep stateful undos in client
Google Drive realtime SDK
collaboriatvely edited map, with OT (something Transform)

“Model, Controller, Syncing”
shared among webui / mobile ui

first try: teams centered around platform
second try: teams organized around product

paxos concesus for oracle that maps doc to to single server
CAP – availability vs consistency
picks consistency

“product design / limits in a distributed system is tied to your architecture”

in google docs: CAP in action – at > 100 QPS, spin up read replica
google forms: answers are communicative and idempotent – allows much higher QPS

google sheets recent upgrade: the move of spreadsheets from idempotent messages to OT messages

“one in a billion happens all the time”

big teams
lots of retraining, people in and out, lots of people
higher calibur engineers helps
people like working on things that people use

balance between “people’s feelings and families” and “technical junk” – two people
technical lead (“greens”) vs human lead (“blues”)
ratio: more greens than blues