An e-commerce platform must preserve ordering correctness during a traffic spike, not merely render the homepage quickly. Product browsing, stock reservation and payment confirmation have different consistency and capacity requirements.
Cache only what is safe to share
Public product descriptions are different from a user's cart, negotiated price or account details. MDN HTTP caching explains HTTP caching controls. Configure shared-cache behavior deliberately and test that personalized responses cannot be returned to another user.
| Workload | Main concern | Useful check |
|---|---|---|
| Product browsing | Read latency and cache freshness | Changed product appears as intended |
| Cart | User-specific state | One user's cart stays private |
| Stock reservation | Concurrent writes | Last unit is not sold twice |
| Payment callback | Durable processing | Duplicate event does not duplicate fulfillment |
Design for delayed confirmation
In a hypothetical peak sale, a payment provider may confirm an operation after the user's browser disconnects. Keep a durable pending order and reconcile its outcome. Stripe webhook delivery documents Stripe delivery behavior, including duplicates and lack of guaranteed order; confirm your provider's contract.
Use representative load
Test authorized staging with realistic product counts, queries and checkout paths. A cached homepage-only test does not measure database writes or integration limits. Define acceptable completion time, error handling and recovery before running the test.
Keep an operating playbook
Record how to detect a growing queue, pause a failing integration and recover unresolved orders. Know which limits belong to the platform, database and external providers. Scaling an application instance cannot remove a payment API limit or a conflicting inventory rule.
For web development, scope the browse-to-fulfillment path and the expected peak scenario. Preserve a repeatable baseline so later changes can be compared on the same work.