API Optimization Tale: Monitor, Fix and Deploy (on Friday)
summary
A green Jenkins build gets pushed Friday to test a billing extraction from a Rails monolith and exposes a REST API that collapses under small traffic; a move to GraphQL plus feature flags and detailed per-request logging (method, args, stack trace, timings) enables reproducing hotspots. Fixes include batching to replace thousands of N+1 external calls with a single fetch and index (batch-fetch and index), switching a frequently read field to a local read model instead of Kafka, fixing an overzealous sanitization that caused a 10x memory spike and a 1‑minute Postgres query, and finally adding spread/jitter and a Sidekiq limiter so the changes actually hold.
AI-written summary · about
chapters (10)
- 0:00Introduction and speaker welcome
- 3:39Project background and monolith challenges
- 8:16Safe extraction with feature flags
- 11:47Monitoring and feedback loop setup
- 17:50Optimizing N+1 queries with caching
- 23:55Production incident and recovery
- 27:35Ongoing issues and time zone spikes
- 30:27Confidence in Friday deployments
- 35:11Key learnings and takeaways
- 41:46Q&A session
related talks
45mMonitor, Fix and Deploy (on Friday)
54mOptimizing performance in Rails apps with GraphQL layer
35m"10 performance sins of Rails applications"
30mRails Performance monitoring: A primer for developers
21mBuilding a Performance Analytics Tool with ActiveSupport
26mRails Performance Monitoring 101: A Primer for Developers
01h 03mRuby at Scale
30mOn API Optimization
