Skip to main content

Applying Performance Testing: AtlasShop Checkout Under Load

Prerequisites: You should already have completed Applying Performance Testing: AtlasBank Loan Application Under Load. Leads to: After this, you'll be ready for Common Mistakes in Performance Testing.

Every AtlasBank example in this path has involved steady, predictable traffic — the shape banking usage actually has. This module deliberately steps outside it: AtlasShop, continuing Database Testing's own contrasting-domain precedent, with a genuinely different load shape — bursty, sale-driven spikes rather than steady accumulation — practicing this path's full toolkit against a load pattern none of AtlasBank's own examples needed to test for.

The Feature: AtlasShop Flash-Sale Checkout​

Verifying AtlasShop's checkout flow — cart, inventory reservation, and payment — under a flash-sale traffic pattern: a large, near-simultaneous surge as a sale begins, rather than banking's gradual, predictable accumulation.

Strategy and Metrics (Sections 1–2)​

Applying Performance Testing Strategy: flash-sale checkout ranks as the highest-priority candidate — extreme traffic concentration in a short window, high business criticality (a failed checkout during a sale is lost, not deferred, revenue), a load shape fundamentally unlike AtlasBank's steady traffic. Applying Performance Metrics and SLAs: the SLO is set specifically around the sale's opening minutes (p95 under 2,500ms for the first 5 minutes), since that narrow window — not steady-state average traffic — is where real risk concentrates.

Execution and Tools (Section 3)​

Applying Performance Testing Types: a spike test is the primary test type here, not load or stress — matching the feature's actual, defining risk shape, the same deliberate type-matching Performance Testing Strategy taught. Applying Bottleneck Analysis and Monitoring: monitoring specifically includes the inventory-reservation data layer, given Database Testing's own prior finding on this exact schema.

A real finding surfaces here: the spike test reproduces, under real concurrent load, the same overselling lost-update pattern Database Testing's AtlasShop module originally found through deliberate concurrent testing at the data layer — but at spike-level concurrency, it additionally produces a cascading effect Database Testing's own narrower test never triggered: a growing backlog of retried, failed reservation attempts as customers' clients automatically retry the failed checkout, further amplifying load precisely during the highest-risk window. This is a genuinely new performance-specific finding: the same underlying defect Database Testing already identified, now shown to actively worsen under real spike conditions in a way a correctness-focused test alone could never reveal.

Analysis and Capacity (Section 4)​

Applying Result Analysis and Reporting: the report explicitly cross-references Database Testing's own finding — this isn't a new defect requiring a new fix, but confirmation that the already-known data-layer fix (atomic check-and-decrement) also resolves the performance-amplification effect, verified by re-running the spike test after the fix ships. Applying Capacity Planning: separately, static asset delivery (product images) is confirmed to hold comfortably under the same spike, an explicitly stated negative finding — confirming the CDN layer is not a capacity concern for this feature, worth stating explicitly rather than leaving unverified.

What This Application Module Shows​

Practicing against AtlasShop's genuinely different load shape confirms something Database Testing's own AtlasShop module also demonstrated: this path's toolkit generalizes, and — distinctively — reveals a real interaction between a previously-found correctness defect and a performance-specific amplification effect neither path alone could have shown. A defect found through deliberate concurrent testing at the data layer, and a defect found through spike testing at the performance layer, turn out to be the same root cause, confirmed independently by two different paths' own techniques.

Common Mistakes​

Mistake 1: Treating AtlasShop's checkout as if it had AtlasBank's steady load shape. A load or stress test alone — the primary types this path's AtlasBank examples relied on — would not have reproduced the spike-specific retry-amplification effect this module found.

Mistake 2: Assuming a data-layer defect already found by Database Testing has no further performance relevance. The retry-amplification effect is a genuinely new, performance-specific finding building on the known defect — re-verifying it under load was still necessary, not redundant.

Mistake 3: Not explicitly stating a negative finding (the CDN held up fine) as part of the report. An unstated "we didn't check this" is different from an explicitly confirmed "we checked this and it's fine" — the latter is real, valuable information for capacity planning.

Best Practices​

Practice 1: Match primary test type to a feature's actual, defining load shape — spike testing for AtlasShop's flash-sale checkout, not load/stress by default. This is what found the real retry-amplification effect a default load-test-first approach would have missed entirely.

Practice 2: Cross-reference known findings from other paths when testing the same underlying schema or feature. Database Testing's own AtlasShop finding directly informed what this module's monitoring specifically watched for — reuse that context rather than starting blind.

Practice 3: State explicit negative findings (what was checked and confirmed fine), not just positive defects. This turns "we didn't get to the CDN" into "the CDN was tested and confirmed not a concern" — a meaningfully different, more useful statement for future planning.

Key Takeaways​

  • AtlasShop's bursty, sale-driven load shape is a deliberate contrast to AtlasBank's steady traffic, and matching test type to actual load shape (spike-first, not load-first) is what surfaces its real risks.
  • This path's toolkit — strategy, metrics, execution, analysis — transferred directly to a schema and load shape none of AtlasBank's own examples needed.
  • A correctness defect found by Database Testing and a performance-amplification effect found by this path's spike test shared the same root cause — confirmed independently by two different paths' own techniques.

What You Just Learned​

  • How to match a feature's primary test type to its actual, defining load shape, rather than defaulting to load/stress testing
  • How a real retry-amplification effect was found by connecting a known data-layer defect to spike-level concurrent load
  • Why cross-referencing findings from other certified paths focuses monitoring and investigation more effectively
  • Why explicitly stated negative findings are valuable, not just positive defects

Next: Common Mistakes in Performance Testing

Interview Questions​

Q1: Why might a known data-layer defect need to be re-verified under a dedicated performance test, even after it's already been found and understood?

What to look for: A candidate who explains that a correctness-focused test (finding a defect exists) and a performance test (finding how that defect behaves and potentially amplifies under real concurrent load) answer genuinely different questions — the second can reveal consequences (like a retry-driven cascade) the first was never designed to show.

Q2: How would you decide which performance test type to prioritize for a new feature you've never tested before?

What to look for: A candidate who describes analyzing the feature's actual, expected real-world load shape (steady vs. bursty, sudden vs. gradual) and matching test type to that shape specifically — not defaulting to load testing as a universal starting point regardless of context.

Glossary​

No new terms are introduced in this module — every concept used above is defined in its linked source module.

Quick Revision​

Remember these five points:

✓ Match primary test type to a feature's actual defining load shape — spike testing for bursty, sale-driven traffic.

✓ This path's toolkit transfers directly to an unfamiliar schema and load shape, the same way Database Testing's own AtlasShop module confirmed.

✓ A correctness defect and a performance-amplification effect can share the same root cause, confirmed independently by different paths' techniques.

✓ Cross-reference known findings from other certified paths when testing the same underlying feature or schema.

✓ State explicit negative findings, not just positive defects — "checked and confirmed fine" is real, useful information.