Peak scenario and capacity plan
Design starts by putting the expected peak into numbers: concurrent users, requests per second and basket or transaction rate. Those numbers come from past campaign data; where none exists they are marked as assumptions and corrected after testing.
- Every assumed number is explicitly marked as one
- Peak duration is planned alongside peak height
- Scaling latency is added to the capacity margin
- The campaign calendar enters the infrastructure calendar
Cache layers and delivery
The fastest request is the one that never reaches the back end. Edge cache, application cache and the layer in front of the database are designed separately, with invalidation rules written against the content lifecycle.
- Invalidation rules cover campaign changes too
- Personalized content is handled in its own layer
- Cache hit ratio is monitored continuously
- The cold-start scenario is tested separately
Back-end resilience
What breaks under peak load is usually not the front end but a back-end dependency. Queues, backpressure, circuit breakers and timeout values are part of the design; the system should keep serving partially even while it slows.
- Timeout values are defined layer by layer
- Circuit breakers stop a failure from spreading
- Queues spread a sudden surge over time
- Partial service beats a full outage
Load testing and real user measurement
Load testing imitates the target scenario; real user measurement shows the experience in the field. Both are used together: the test finds the bottleneck, field measurement confirms the design was right.
- Test scenarios are derived from real user journeys
- Field measurement exposes device and network diversity
- Bottleneck findings become remediation items
- Results feed the pre-campaign decision meeting