Case Study · Backend & Cloud

Backend & Cloud

Problem
Burst uploads overwhelmed fixed worker pools; job backlog and API timeouts spiked.
Role
Streamed work through Redis queues, rate-limited FastAPI ingress, and instrumented autoscaling with Prometheus and Grafana.
Stack
Docker Compose, Redis Streams, FastAPI, Prometheus, Grafana
Impact
256-job queue cap with 503 backpressure · 100 req / 60 s rate limit per key

Backend and cloud systems designed for resilient async execution, throughput under bursts, and dependable API behavior.

Operational guarantees: clearer service boundaries, resilient queue handling, and autoscaling that holds under volatile traffic.

Context: baseline captured with fixed worker pools, then compared over 5 weeks after autoscaling and queue policy rollout.

Queue admission & observability

LLM inference control plane: Redis Streams queue and backpressure

Context: Async inference requests needed admission control, observable queue depth, and predictable failure modes under burst load.

Problem: Unbounded enqueue would saturate GPU workers; API callers had no signal when the system was at capacity.

What I built: FastAPI control plane with Redis Streams job queue, sliding-window rate limiting (100 req / 60 s per API key), HTTP 503 backpressure at 256 pending jobs, and Prometheus metrics scraped every 15 s across a 5-service Docker Compose stack.

Impact: Queue saturation returns explicit 503 responses instead of silent degradation; 8 Prometheus metric families track latency, cache hits, rate limits, and queue depth.

Tradeoff I made: Accepted rejected requests at saturation in exchange for predictable worker behavior and debuggable queue signals.

Ops outcomes

Throughput and error-budget behavior during the same burst window as the timeline above.

256

max pending jobs before 503

Config
MAX_QUEUE_DEPTH=256
Behavior
HTTP 503 on saturation
Sample
app/config.py

100/min

rate limit per API key

Window
100 requests / 60 s
Response
HTTP 429 when exceeded
Sample
Sliding-window limiter

Architecture diagram

Backend and cloud architecture diagram

Ingress API -> Redis event queues -> Kubernetes workers -> Storage/outputs -> Autoscaling + observability

Before & After

Before

Traffic spikes created backlog pressure and inconsistent processing times for async media jobs.

queue pressure under burst uploads

After

Autoscaled workers and event-driven execution improved throughput and stabilized processing during peaks.

throughput up 20% with horizontal scaling

Execution Footprint

Core stack and operating patterns used to deliver the outcomes above.

Tech stack

GCP Kubernetes Docker Redis REST APIs

Techniques / models / operations

Event-Driven Workers Autoscaling Rate Limiting Queue Resilience