Kubernetes autoscaling and observability for a flash-sale service

Tezz Cart runs flash sales where traffic jumps from about 500 requests a second to 10,000 in under a minute when a sale opens. Their checkout service, running on a fixed set of servers, falls over every time: requests time out, some orders are lost, and the team watches it fail with no useful numbers to explain why. The last sale was down for seven minutes at peak, which they estimate cost a large chunk of the day's orders.

You will move the checkout service onto Kubernetes and make it survive the spike. That means packaging the service, setting sensible resource requests and limits, and configuring autoscaling so the number of pods grows with load and shrinks again afterwards. It also means observability: metrics, dashboards and alerts that show request rate, latency, error rate and how many pods are running, so the team can see the system react in real time rather than guessing.

You will drive the system with a load test that reproduces the 20-times spike, because you cannot wait for a real sale. Done looks like the service holding its latency and error targets through a simulated flash sale while pods scale out and back in, a dashboard that tells the story of the spike, and alerts that fire on the things that matter. There is a budget too: the autoscaling has a ceiling, so you have to meet the targets without asking for unlimited pods. Tezz Cart signs off when a simulated sale keeps errors under 1% and the dashboard explains, without anyone touching a terminal, what the system did.