Web app on Kubernetes
A load balancer spreads requests over app pods on Kubernetes, which check Redis before going to PostgreSQL.
Click any box to open its page. Open it in the playground to rewire it, change the traffic or take parts down.
The workhorse shape for a web product that outgrew one server. Your app is packaged as a container image and runs as several identical pods on Kubernetes, which restarts them when they crash and adds more when they’re busy. A load balancer spreads traffic across them. Frequently read data is answered from a Redis cache, so PostgreSQL only handles the misses and the writes.
How it flows
- 1
The load balancer picks a healthy pod
An Application Load Balancer receives each request and forwards it to one of the pods registered as healthy. A pod that fails two health checks in a row (sent every 30 seconds by default) stops getting traffic.
- 2
Kubernetes keeps the pods running
A Deployment asks for three replicas of the
apiimage. If one crashes or its node dies, Kubernetes starts a replacement; a HorizontalPodAutoscaler can add replicas when CPU climbs. - 3
Redis answers the common reads
The app looks up the key in Redis first. On a hit it returns immediately; on a miss it queries PostgreSQL and stores the result in Redis with an expiry, so the next request is a hit.
- 4
PostgreSQL holds the truth
All writes and cache misses go to PostgreSQL. It’s the one stateful piece, so it usually runs as a managed service with a standby replica and automatic backups.
Why this shape works
- Pods are interchangeable, so losing one costs nothing but a little capacity
- The cache takes most of the read load off the database, which is the hardest part to scale
- The same container image runs in development, CI and production
- Kubernetes gives one way to deploy, scale and roll back every service the team runs
Where it strains
- Kubernetes itself is a system to learn, upgrade and secure; managed offerings help but don’t remove that
- Cache invalidation: after a write, stale entries must be deleted or allowed to expire
- PostgreSQL is still one primary; heavy write growth eventually needs read replicas, partitioning or sharding
- If Redis goes down, every request becomes a miss; make sure the database can survive that surge
Common swaps
Add Prometheus to scrape every pod and Grafana to chart it, so you see the cache hit rate and database latency.
Built from
AWS Application Load BalancerAWSLoad balancersAWS’s managed layer-7 load balancer: routes HTTP requests by host, path or header to EC2, containers, IPs or Lambda.