API Horror Stories from an Unnamed Coworking Company
summary
Eighteen months of daily P0/P1 firefighting yields concrete fixes: two giant mutually dependent monoliths cause 20–30s synchronous calls across ~50–100 APIs, no timeouts, and regular cache stampedes. Diagnosis uses a Faraday 0.9.1 fingerprint across GitHub, and mitigation copies User+Company logic into a separate Keycard service, adds timeouts, a proxy, and an async background queue so keycard failures no longer take the whole company down. Other remedies: add a tiny cached locale endpoint, deploy OpenAPI design‑first docs with Stoplight, and enable tracing via OpenTelemetry/service mesh.
AI-written summary · about
chapters (10)
- 0:00Introduction to API horror stories
- 3:29API design first workflow explained
- 8:03Stoplight tools and solutions
- 8:25Cache stampede Cluedo explained
- 12:18Distributed monolith problems
- 15:10Why timeouts are essential
- 21:53Busy day in Australia nobody poops
- 29:03Mutually assured destruction
- 32:12Solutions and best practices
- 33:39Q&A session
related talks
48mTransforming a monolith to an API platform
25mDesigning and Testing Resilient APIs for India Scale
42mAvoiding Microservice Megadisaster
42mArrested Development: surviving the awkward adolescence of a microservices-based application
42mArchitecting for Failures in Microservices
24mAPI as the powerful EA lighthouse for a Composable Information System.
40mGive It a REST – Tips for Designing and Consuming Public API’s
33mArrested Development