Functional Programming & NoSQL Design
summary
Built a distributed job scheduler called Cook that runs on clusters with tens of thousands of CPUs using immutable data and structural sharing; immutability plus path‑copying reduces data races and concurrent modification errors and makes rollbacks and reprocessing cheap. Uses NoSQL patterns (examples: DynamoDB/Cassandra/BigTable) with single‑key transactions, name objects by UUID + fat keys (username, category, timestamps) to avoid serialization and provide isolation, and push continuations into queues with persisted request IDs so workers can retry, debug, and swap datasets atomically.
AI-written summary · about
chapters (17)
- 0:00Start
- 1:16ABOUT DAVID GREENBERG
- 2:17IMMUTABILITY ON A SINGLE MACHINE
- 6:09WHAT ENABLES IMMUTABILITY?
- 7:47WHY DO WE LIKE IMMUTABILITY?
- 10:33PASSING AROUND DATA EFFICIENTLY
- 11:59STORE IT SOMEWHERE SECURE
- 12:23IMMUTABILITY AT A DISTANCE
- 13:56IMMUTABILITY EXAMPLE
- 17:54EXAMPLE: IMAGE HOST
- 19:27EXAMPLE: BLOG ENGINE
- 21:37THE CHALLENGE
- 22:24FLOW GRAPH CALL TREE
- 24:15EXAMPLE: SUBSCRIPTION SERVICE
- 25:58EXAMPLE: BIG DATA PROCESSING
- 27:14ROADMAP RECAP
- 27:53BONUS CONTENT
related talks
32mFunctional Programming for (Dev)Operations and Infrastructure
29mModern Database Architecture: From SQL to NoSQL & Distributed SQL
42mFunctional Programming in 40 Minutes
51mImmutable data stores and CORS for safety, flexibility and profit
34mData Storage: NoSQL Toasters and a Cloud of Kitchen Sinks
34mThe Road to Hype: How NoSQL became Serverless
01h 32mDistributed functional programming
01h 44mFunctional Programming: Technical Reasons to Adapt