Add Simplicity to Complex Systems
summary
Describes building a geo-distributed time‑series database (used in production) that chooses LuaJIT embedding to let data scientists run fast safe code, swaps through four or five embedded DBs until append‑optimized storage wins, and spends six years evolving a concurrency pools system for fairness and throttling. Argues to delay general APIs until multiple consumers exist, accept intentional boundary violations for performance, and treat abstractions as loans with measurable interest.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 3:59Software abstraction concepts
- 6:24Microservices improve design
- 10:39Premature abstraction dangers
- 13:32Imperfect systems inevitability
- 16:04Abstraction as technical debt
- 19:16Database abstraction pitfalls
- 21:01Concurrency limits in performance
- 23:12Abstraction design lessons
- 27:45Abstraction violations cost
- 29:11Microservices trends
- 31:00API-first misconceptions
- 32:29Libraries as products
- 33:57Complexity versus reliability
- 36:08Abstraction leaks versus violations
- 37:30When to decompose microservices
- 39:18Q&A
related talks
38mAdding Simplicity to Complexity
40mArchitecting for Data-Intensive Workloads
01h 17mWhen Less Is More: Designing & Decoding Complex Distributed Systems
01h 29mMonolithic Delivery
26mThe Power of Simplicity: Crafting Durable Software Systems
43mEvident Code, at Scale
01h 02mTools for simplified large scale systems
29mDeprecating Simplicity