A festival ticketing spike must capture purchase events and analytics without collapsing checkout. What architecture emphasis is required?
Select an answer to reveal the explanation.
Short Explanation
When the gates open, the click stream turns into a fire hose. Architecture has to soak up events and still keep checkout standing — not wait for a box of paper stubs next week.
Full Explanation
Ticketing and high-transaction event patterns emphasize scalable event capture, resilient purchase paths, and analytics that do not block checkout. Festival spikes are a classic civic stress test of that design when residents buy access en masse. Separating throughput concerns from user-facing transaction health is the architectural takeaway.
A monthly batch of paper stubs counted after the festival fails by concept: post-hoc paper cannot handle spike capture. Turning off analytics permanently so checkout never shares infrastructure planning fails by concept: analytics and checkout still need planned separation, not analytics abandonment. Storing tickets only as handwritten ledgers with no event stream fails by concept: handwritten ledgers fail under load.
Exam caveat: High-throughput transactional/event architecture scales capture and analytics separately from checkout resilience—not paper batches, analytics deletion, or handwritten-only ledgers.
Operational check: Load-test ticket purchase under spike, ensure analytics consumers cannot block checkout, and verify event capture remains durable during peak. Document residual risk for civic operators and revisit after the next production change window.