The Global Lock Bottleneck
#sre-critical — loyalty API throughput collapsed
SRE: /api/redeem-points dropped from 5,000 req/s to ~4 req/s. Dev wrapped the entire handler in a global mutex — including 200ms DB fetch and save.
The trap: Lock held during slow I/O → every thread waits in a single-file line.
Your task
Fix `redeem_points()` in `points_service.py`: fetch and save outside self.lock; lock only the in-memory balance update.
Book: mutex prevents races · Prod: lock granularity — protect shared state, not slow I/O.
Skills you'll prove
Interview Tip
When asked about mutexes or thread safety, say: "A lock only protects the shared state that actually races — not your entire request handler. I debugged a loyalty API where throughput collapsed from thousands of req/s to single digits because someone wrapped the whole handler in a mutex, including a 200ms database query. Every thread waited in line for I/O that didn't need locking. The fix was lock granularity: fetch outside the lock, lock only for the in-memory balance update, save outside the lock. In production, hold locks for microseconds, not milliseconds."