Meta·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

Meta system design round for a software engineer role, focused entirely on building a Ticketmaster-style ticketing platform. Pretty deep scope for a single question and I felt like I was playing catch-up for most of it.

Questions Asked (1)

Design a large-scale ticketing system similar to Ticketmaster, scoped to general admission events. Walk through the data model, purchase flow, inventory holds with expiry, oversell prevention, payment integration, idempotency, surge handling at on-sale time, and refunds.

System DesignData ModelingTechnical Trade-offs

Author's notes

This question is basically five questions duct-taped together and they want you to cover all of it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale (e.g., millions of users, high concurrency at on-sale), then design a data model that separates events, seats (if assigned) or general admission pools, and orders. Walk through the purchase flow with inventory holds, payment integration, and idempotency, emphasizing oversell prevention via atomic operations and surge handling with queues and caching.

Pro tip: Emphasize the trade-offs between strong consistency and availability during on-sale surges, and propose a hybrid approach: use a relational database for inventory with row-level locking for strong consistency, and a distributed cache/queue for surge absorption. This shows you understand both correctness and scalability.

1. Clarify Requirements and Scale

Ask about expected traffic (e.g., millions of concurrent users), read/write ratio, consistency needs, and whether general admission means no assigned seats. Define functional and non-functional requirements.

2. Design Data Model

Propose tables for events, ticket types (general admission pools), inventory (with available count), orders, and payments. Consider using a relational DB for ACID guarantees on inventory updates.

3. Purchase Flow with Holds and Idempotency

Outline steps: user selects quantity, system creates a hold with expiry (e.g., 10 minutes) by atomically decrementing inventory, user pays, hold converts to order. Use idempotency keys to prevent duplicate charges and double decrements.

4. Oversell Prevention and Surge Handling

Prevent oversell via atomic decrement (e.g., UPDATE ... WHERE available >= quantity) or distributed locks. Handle surges with queueing (e.g., virtual waiting room), rate limiting, and caching to protect the database.

5. Payment Integration and Refunds

Integrate with payment gateway (e.g., Stripe) using idempotent requests. For refunds, implement a process that reverses payment and increments inventory, ensuring consistency and handling failures with retries and compensation.

Key Points to Mention

Atomic inventory decrement to prevent oversell (e.g., database transaction with row lock or conditional update).
Idempotency keys for payment and order creation to handle retries and duplicate requests.
Inventory holds with expiry using a temporary reservation system (e.g., Redis with TTL or database with expiration timestamp).
Surge handling via virtual waiting room, queueing, and rate limiting to smooth traffic spikes.
Payment integration with idempotent APIs and handling of asynchronous payment confirmations.
Refund process that restores inventory and ensures idempotent refund operations.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.