Why today, more then ever you need Dependency Isolation in Distributed Systems
summary
Argues that isolating dependency flows prevents cascading failure and cost blowouts, showing a simple postal-style architecture that uses load shedding at the gateway to drop doomed requests (keeps throughput higher, saves CPU) and a bucket token per-customer model (10k/min limits, short bursts of 20–60s to borrow unused capacity) implemented with Redis-like stores and bucket-forj, plus AWS SQS-style dynamic queue creation and AWS time sync/atomic-clock timestamps to enable reliable fail‑fast decisions and lower autoscaling spend.
AI-written summary · about
chapters (25)
- 0:00Introduction
- 1:10Why dependency isolation matters
- 2:33Real-world example
- 5:24Load shedding
- 8:13Payment systems evolution
- 9:34Fairness and rate limiting
- 14:32Retry failed requests
- 15:36Isolating payment dependencies
- 19:10Cost of cascading failures
- 20:36Timeouts pitfalls
- 23:04Time in distributed systems
- 25:14Atomic clocks for time
- 26:42Stock market time example
- 28:46FIFO vs LIFO
- 30:54Monitoring role
- 31:56Serverless scaling
- 34:24Dependency isolation recap
- 37:38Fail-fast and load shedding
- 39:03Time as decision tool
- 40:29When not to retry
- 43:21Modern frameworks
- 45:25Dynamic timeouts
- 47:10Burst capacity
- 49:17Implementing patterns
- 51:31Q&A
related talks
25mAvoiding Overload in Distributed Systems
02h 42m!!! Do not publish or share !!!!
30mDistributed system design
52mDistributed Computing Dealing with Time and Failure in the Wild
51mPatterns for building resilient software systems
35mDesign patterns for application resiliency
34mDistributed Systems - What Can Go Wrong and How to Get It Right
47mEverything Loosely Coupled - Advanced Integration Patterns and Their Trade-Offs