A request should not carry every task.
Blocking workloads can keep an API request waiting for work that belongs in a background process.
Simplified flow · based on the project summary
- 01API request
- 02Redis cache
- 03Async queue
- 04Background work
Case study 04 / Zopper
Redis caching and asynchronous processing behind a 55% reduction in API latency.
01 / The problem
Customer-facing insurance journeys depend on responsive backends. Caching and background processing create opportunities to avoid repeating work or making a request wait for an unrelated task.
Blocking workloads can keep an API request waiting for work that belongs in a background process.
Simplified flow · based on the project summary
03 / What I changed
Used Redis caching to reduce API latency.
Moved blocking workloads into Celery queues and Redis Pub/Sub.
Built Django microservices for customer-facing policy purchase journeys.
Caching raises questions about freshness and invalidation; moving work into a queue changes how completion is communicated. Those are the relevant engineering trade-offs. This summary does not invent a cache-hit rate, delivery guarantee, or a detailed queue policy.
04 / The result
API latency was reduced by 55%. Separately, latency-sensitive policy-purchase transaction flows maintained 200 ms p95; the two résumé claims are not treated as a single before-and-after benchmark.
Reported project outcomes from my résumé. Diagrams are simplified explanations, not production topology or benchmark telemetry.
Continue exploring