Ingressos (Venda Relâmpago do BoxOffice)

"Projete uma plataforma de ingressos como a Ticketmaster. Um show de estádio abre as vendas às 10:00: dois milhões de fãs, sessenta mil lugares. Ninguém pode ficar com o mesmo lugar duas vezes."

Este é o caso principal da disciplina porque é o próprio BoxOffice, e porque reúne num só problema as ideias mais difíceis do semestre: um pico 100× maior que a carga normal que chega em segundos, um recurso quente e fortemente consistente (os lugares) que não dá para esconder atrás de um cache, uma dependência externa (o provedor de pagamento) lenta e às vezes fora do ar, e tráfego adversário (bots e cambistas). A maior parte do sistema é um catálogo chato e de muita leitura; a entrevista se decide nos dez minutos depois das 10:00.

1. Esclarecer os requisitos

Gaste os primeiros cinco minutos aqui (veja o roteiro de entrevista). Um sistema de ingressos pode ser "a bilheteria de um teatro de 300 lugares" ou "a abertura de vendas da Eras Tour": as respostas abaixo mudam o design por completo.

Requisitos funcionais

1. Fãs navegam por eventos e locais (catálogo) e veem o mapa de lugares com disponibilidade ao vivo.
2. O fã escolhe lugares e recebe uma reserva (hold): os lugares ficam guardados para ele por alguns minutos (ex.: 10 min) enquanto paga.
3. O fã paga por um provedor de pagamento externo; com sucesso, o pedido é confirmado e os ingressos são emitidos (e-mail + app).
4. Reservas não pagas expiram e os lugares voltam à venda.
5. Em aberturas de alta demanda, os fãs aguardam numa sala de espera e são admitidos em ordem.

Requisitos não funcionais

Fora do escopo (diga explicitamente)

Cadastro de eventos pelos produtores, preço dinâmico, marketplace de revenda, leitura física dos ingressos no portão, reembolsos. Cite-os numa frase e siga em frente.

2. Estimativas de guardanapo (back-of-the-envelope)

Os números é que tornam este problema interessante: o trabalho total é minúsculo (60 mil lugares cabem em poucos megabytes), mas o pico é brutal. Declare as premissas e depois calcule. O bloco abaixo é a estimativa em código — abra a aba Source, mude uma premissa e refaça no papel.

# BoxOffice flash sale: assumptions (illustrative, change them freely)
fans        = 2_000_000   # fans who show up for the on-sale
arrival_s   = 120         # most of them arrive within ~2 min of 10:00
seats       = 60_000
per_order   = 2           # tickets per order (average)
checkout_s  = 300         # time an admitted fan spends choosing + paying
active_cap  = 10_000      # shoppers the inventory + payment path can serve at once
conversion  = 0.6         # admitted fans who end up buying
poll_s      = 10          # waiting-room status refresh interval
page_kb     = 100         # waiting-room page + assets
psp_s       = 2.0         # payment provider latency

orders       = seats / per_order
join_rate    = fans / arrival_s                 # joins per second at the door
no_queue_rps = fans * 5 / 60                    # 5 requests/fan in the 1st minute, no queue
naive_poll   = fans / poll_s                    # status polls if all hit the origin
admit_rate   = active_cap / checkout_s          # Little's Law: L = λ·W  →  λ = L / W
admits       = orders / conversion
sellout_min  = admits / admit_rate / 60
order_rate   = admit_rate * conversion
pay_inflight = order_rate * psp_s               # Little's Law again
seat_map_rps = active_cap / 3                   # each shopper refreshes the map every 3 s
edge_gb      = fans * page_kb / 1e6
inventory_mb = seats * 100 / 1e6                # ~100 B per seat row

rows = [
    ("orders", orders, ""), ("join_rate", join_rate, "req/s"),
    ("no_queue_rps", no_queue_rps, "req/s"), ("naive_poll", naive_poll, "req/s"),
    ("admit_rate", admit_rate, "fans/s"), ("admits", admits, "fans"),
    ("sellout_min", sellout_min, "min"), ("order_rate", order_rate, "orders/s"),
    ("pay_inflight", pay_inflight, "calls"), ("seat_map_rps", seat_map_rps, "req/s"),
    ("edge_gb", edge_gb, "GB"), ("inventory_mb", inventory_mb, "MB"),
]
print("| quantity | value | unit |\n|---|---:|---|")
for name, value, unit in rows:
    v = f"{value:,.0f}" if abs(value) >= 100 else f"{value:,.2f}"
    print(f"| `{name}` | {v} | {unit} |")

O que os números dizem — este parágrafo é o que o entrevistador quer ouvir:

• Sem sala de espera, o estoque veria ~170 mil requisições/s durante um minuto. Um único primário PostgreSQL faz alguns milhares de pequenas transações de escrita por segundo; nenhuma quantidade de servidores de aplicação resolve, porque o gargalo é um punhado de linhas quentes. ⇒ precisamos de controle de admissão.
• Com 10 mil compradores simultâneos e 5 minutos cada, a Lei de Little dá uma taxa de admissão de ~33 fãs/s (2 000/min), esgotamento em ~25 minutos e apenas ~20 pedidos/s — tranquilo para um banco bem indexado.
• A própria sala de espera precisa aguentar ~17 mil entradas/s e, se todo mundo consultar a origem, 200 mil consultas/s. ⇒ sirva a página pela CDN e torne o endpoint de status barato (um token assinado + a leitura de um único contador, cacheável por um segundo).
• Cerca de 40 chamadas de pagamento estão em andamento a qualquer momento (20/s × 2 s). ⇒ dimensione o pool de conexões e o bulkhead do adaptador de pagamento para isso, não para os 2 M de fãs.
• O estoque inteiro tem ~6 MB: armazenamento não é problema; disputa (contention) é.

3. API

Mantenha curta e orientada a recursos; os campos interessantes são os tokens e a chave de idempotência.

POST /v1/events/{eventId}/queue                      → 201 {queueToken, position, etaSeconds}
GET  /v1/queue/{queueToken}                          → 200 {status: WAITING|ADMITTED, position, accessToken?}

GET  /v1/events/{eventId}                            → 200 event, venue, price levels   (CDN, minutes)
GET  /v1/events/{eventId}/availability?section=A     → 200 {seatsBitmap, version}      (cache, 1 s)

POST /v1/events/{eventId}/holds                      → 201 {holdId, seats, expiresAt} | 409 SEAT_TAKEN
     Authorization: Bearer <accessToken>
     Idempotency-Key: 7f3c…
     {"seatIds": ["A-12-07", "A-12-08"]}
DELETE /v1/holds/{holdId}                            → 204

POST /v1/orders                                      → 202 {orderId, status: PENDING_PAYMENT, paymentUrl}
     Idempotency-Key: 9a41…
     {"holdId": "…"}
GET  /v1/orders/{orderId}                            → 200 {status: CONFIRMED|PENDING_PAYMENT|EXPIRED|FAILED}

POST /v1/webhooks/payments                           ← provider callback, signed (HMAC)

• O accessToken é o que a sala de espera entrega: um token assinado de vida curta (ex.: um JWT com eventId, userId, exp = 15 min). O gateway recusa chamadas de reserva/pedido sem um token válido, então ninguém fura a fila chamando a API diretamente.
• Idempotency-Key em reservas e pedidos: redes móveis repetem requisições, usuários dão clique duplo; o servidor guarda a chave com a resposta e a devolve de novo em vez de criar uma segunda reserva ou pedido.
• POST /v1/orders devolve 202 Accepted: o pagamento é assíncrono; o cliente consulta o pedido (ou recebe um push) até ficar CONFIRMED.

4. Modelo de dados

O estoque é pequeno, relacional e precisa de transações ⇒ SQL (PostgreSQL), particionado por event_id se houver muitos eventos. O catálogo é quase só leitura e pode morar no mesmo banco atrás de um cache, ou num banco de documentos.

CREATE TABLE seat (
    event_id     BIGINT      NOT NULL,
    seat_id      TEXT        NOT NULL,             -- 'A-12-07' (section-row-number)
    section      TEXT        NOT NULL,
    price_cents  INT         NOT NULL,
    status       TEXT        NOT NULL DEFAULT 'AVAILABLE',  -- AVAILABLE | HELD | SOLD
    hold_id      UUID,
    held_until   TIMESTAMPTZ,
    version      INT         NOT NULL DEFAULT 0,
    PRIMARY KEY (event_id, seat_id)
);

CREATE TABLE hold (
    hold_id      UUID PRIMARY KEY,
    event_id     BIGINT      NOT NULL,
    user_id      BIGINT      NOT NULL,
    expires_at   TIMESTAMPTZ NOT NULL,
    status       TEXT        NOT NULL               -- ACTIVE | CONVERTED | EXPIRED | RELEASED
);

CREATE TABLE ticket_order (
    order_id        UUID PRIMARY KEY,
    hold_id         UUID UNIQUE NOT NULL,           -- one order per hold
    user_id         BIGINT NOT NULL,
    total_cents     INT    NOT NULL,
    status          TEXT   NOT NULL,                -- PENDING_PAYMENT | CONFIRMED | FAILED | EXPIRED
    payment_ref     TEXT,                           -- provider's id
    idempotency_key TEXT UNIQUE NOT NULL,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE outbox (                               -- transactional outbox → Kafka
    id BIGSERIAL PRIMARY KEY, topic TEXT, payload JSONB, created_at TIMESTAMPTZ DEFAULT now()
);

5. Design de alto nível

Leia o diagrama como dois caminhos. O caminho barato (catálogo, página de espera, disponibilidade) é servido pela CDN e pelos caches e nunca toca as linhas quentes. O caminho caro (reserva → pedido → pagamento) é protegido pela sala de espera, que deixa entrar só o que o banco e o provedor de pagamento aguentam.

flowchart LR
    fan([Fã / mobile]) --> cdn["CDN<br/>páginas de evento, página de espera"]
    cdn --> waf["WAF<br/>bots, DDoS"]
    waf --> gw["API Gateway<br/>auth, rate limit,<br/>checagem do access token"]
    gw --> wr["Sala de espera"]
    wr --> q[("Fila<br/>sorted set no Redis")]
    gw --> cat["catalog"]
    cat --> cache[("Cache<br/>disponibilidade 1 s")]
    gw --> inv["inventory<br/>reservas"]
    inv --> sql[("PostgreSQL<br/>seat, hold, order")]
    gw --> ord["order"]
    ord --> sql
    ord --> pay["adaptador de pagamento"]
    pay --> psp[["Provedor de pagamento"]]
    psp -. webhook .-> pay
    sql -. outbox .-> kafka[["Kafka<br/>eventos de pedido"]]
    kafka --> notif["notification"] --> email[["E-mail / push"]]
    kafka --> an["analytics"]
    sched["scheduler<br/>expira reservas"] --> sql

O caminho feliz de um fã, passo a passo:

sequenceDiagram
    autonumber
    participant F as Fã
    participant W as Sala de espera
    participant I as inventory
    participant O as order
    participant P as Provedor de pagamento
    participant N as notification
    F->>W: entra (10:00:03)
    W-->>F: queueToken, posição 48 210
    F->>W: consulta status (a cada 10 s, em cache)
    W-->>F: ADMITTED + accessToken (15 min)
    F->>I: POST /holds {A-12-07, A-12-08} + accessToken
    I->>I: UPDATE condicional (os dois lugares ou nenhum)
    I-->>F: 201 holdId, expiresAt = agora + 10 min
    F->>O: POST /orders {holdId} + Idempotency-Key
    O->>P: cria pagamento (chave de idempotência = orderId)
    O-->>F: 202 PENDING_PAYMENT, paymentUrl
    P-->>O: webhook: pagamento aprovado
    O->>O: lugares SOLD, pedido CONFIRMED, linha no outbox (uma transação)
    O-)N: OrderConfirmed (Kafka)
    N-->>F: e-mail + push com os ingressos

6. Aprofundamentos (deep dives)

O entrevistador vai escolher um ou dois destes. Comece pelo que protege a corretude (reservas), depois o que protege a disponibilidade (a sala de espera).

6.1 Reservas de lugar sem venda duplicada

Dois fãs clicam no lugar A-12-07 no mesmo milissegundo. Exatamente um deve ganhar. Há quatro formas clássicas de garantir isso (transações e isolamento):

BEGIN;
UPDATE seat
   SET status = 'HELD', hold_id = $1, held_until = now() + interval '10 minutes',
       version = version + 1
 WHERE event_id = $2
   AND seat_id = ANY($3)
   AND (status = 'AVAILABLE' OR (status = 'HELD' AND held_until < now()));
-- the app checks: rows updated == number of seats requested, otherwise ROLLBACK → 409
INSERT INTO hold (hold_id, event_id, user_id, expires_at, status)
     VALUES ($1, $2, $4, now() + interval '10 minutes', 'ACTIVE');
COMMIT;

BEGIN;
SELECT seat_id, status, held_until FROM seat
 WHERE event_id = $1 AND seat_id = ANY($2)
 ORDER BY seat_id
   FOR UPDATE;            -- NOWAIT or SKIP LOCKED for "best available"
-- app checks every row is free, then UPDATE ... ; COMMIT

UPDATE seat SET status = 'HELD', hold_id = $1, version = version + 1
 WHERE event_id = $2 AND seat_id = $3 AND version = $4;   -- 0 rows → somebody won, retry

SET hold:42:A-12-07 3f9a... NX EX 600   →  OK  (you got it)  |  nil (taken)

Expiração. Uma reserva precisa acabar mesmo que o fã feche o navegador. Combine (a) expiração preguiçosa no comando de reserva (um lugar HELD expirado conta como disponível), (b) um job do scheduler que varre as linhas de hold com expires_at < now() a cada poucos segundos e devolve os lugares para AVAILABLE, para o mapa ficar correto, e (c) estender a reserva enquanto um pagamento está em andamento, para que um fã que está pagando não perca o lugar no segundo 601.

6.2 A sala de espera (fila virtual)

A sala de espera é descarte de carga com boas maneiras: em vez de deixar 2 M de requisições baterem no estoque e falharem ao acaso, ela transforma a rajada num fluxo constante e medido e diz a cada fã onde ele está.

flowchart LR
    j["Fãs entram<br/>~17 mil/s"] --> rq[("Fila<br/>por sorteio<br/>ou chegada")]
    rq --> d{"Admissor<br/>a cada segundo"}
    d -->|"admite λ = L / W<br/>≈ 33 fãs/s"| tok["accessToken<br/>(assinado, 15 min)"]
    tok --> shop["Comprando<br/>≤ 10 mil ao mesmo tempo"]
    shop -->|"compra ou expira"| out([sai])
    out -. libera uma vaga .-> d

Pontos de design:

1. Página estática na CDN. A página de espera é HTML + JS em cache na borda; a única chamada dinâmica é a consulta de status, respondida pelo Redis (ZRANK para a posição) ou por um número "atendendo agora" em cache — o cliente compara com o próprio número, então a origem responde um valor só para todo mundo.
2. Taxa de admissão pela Lei de Little. O admissor deixa entrar λ = L / W fãs por segundo, onde L é o número de compradores que o caminho de checkout consegue atender (medido no teste de carga, ex.: 10 mil) e W o tempo que cada um passa (5 min). É um laço fechado: admite mais quando compradores saem cedo, admite menos quando o p99 de POST /holds sobe ou o provedor de pagamento fica lento.
3. Justiça. FIFO puro premia quem tem a conexão mais rápida — normalmente os bots. Uma política comum: todos que chegam antes das 10:00 recebem uma posição aleatória às 10:00 (um sorteio), e quem chega depois vai para o fim da fila em ordem de chegada.
4. Tokens, não sessões. A admissão gera um accessToken assinado (evento, usuário, validade). O gateway verifica a assinatura localmente — sem armazenamento de sessão compartilhado no caminho quente — e aplica o "máximo de 6 ingressos por conta".
5. Bots. O WAF faz pontuação de bots, rate limit por IP/ASN e desafios; exigir uma conta logada e verificada para entrar na fila é o filtro mais forte. Queue-it, Cloudflare Waiting Room e a solução AWS Virtual Waiting Room são produtos reais construídos sobre essas ideias.

6.3 Checkout e pagamento: uma máquina de estados, não uma chamada de função

Um provedor de pagamento responde em segundos, dá timeout e às vezes chama você de volta antes de sua requisição HTTP retornar. Modele o pedido como uma máquina de estados cujas transições são idempotentes (integrações, caso do sistema de pagamentos).

stateDiagram-v2
    [*] --> HELD: POST /holds
    HELD --> PENDING_PAYMENT: POST /orders (estende a reserva)
    HELD --> EXPIRED: TTL (10 min) acaba
    PENDING_PAYMENT --> CONFIRMED: webhook aprovado
    PENDING_PAYMENT --> FAILED: webhook falhou / recusado
    PENDING_PAYMENT --> CONFIRMED: conciliação encontra o pagamento
    FAILED --> HELD: tenta outro cartão (reserva ainda válida)
    EXPIRED --> [*]
    CONFIRMED --> [*]

• Chave de idempotência para o provedor = orderId. Se o adaptador der timeout e repetir, o provedor devolve o mesmo pagamento em vez de cobrar duas vezes.
• Os webhooks são a fonte da verdade do resultado; são assinados (HMAC), podem chegar duas vezes ou fora de ordem, então o handler é UPDATE ticket_order SET status='CONFIRMED' WHERE order_id=$1 AND status='PENDING_PAYMENT' — uma segunda entrega não muda nada.
• Confirme numa só transação: lugares HELD → SOLD, pedido CONFIRMED, uma linha no outbox. Um relay publica o outbox no Kafka; o notification consome de forma idempotente (deduplica por orderId) e envia o e-mail (padrões de mensageria).
• Conciliação. Um job do scheduler lista pedidos PENDING_PAYMENT com mais de N minutos e pergunta o status ao provedor. Isso resolve webhooks perdidos — e o caso traiçoeiro "o pagamento foi aprovado depois que a reserva expirou": ou os lugares ainda estão livres (confirma) ou foram revendidos (estorna automaticamente e pede desculpas).
• Resiliência. Timeout + circuit breaker + bulkhead em volta do provedor (padrões de confiabilidade); se o breaker estiver aberto, pare de admitir novos fãs em vez de deixá-los reservar lugares que não vão conseguir pagar.

6.4 O caminho de leitura: mapa de lugares e catálogo

Os fãs martelam o mapa de lugares. Servi-lo a partir da tabela seat colocaria as leituras nas mesmas linhas quentes das reservas.

• Mantenha um bitmap de disponibilidade por setor (um bit por lugar — 60 mil lugares = 7,5 kB) no cache, reconstruído a cada segundo a partir do banco ou atualizado pelos eventos de reserva/venda. Os clientes consultam (ou recebem via SSE) com um número de version.
• Aceite desatualização: o mapa pode mostrar como livre um lugar ocupado há 800 ms. O pedido de reserva é a verificação real; devolva 409 SEAT_TAKEN com o bitmap atualizado para a interface se ajustar.
• Pré-aqueça a CDN e o cache antes das 10:00 (página do evento, imagens, bitmaps): um cache frio no momento do pico é um estouro de manada autoinfligido (modos de falha de cache).
• Ofereça o "melhor disponível": o servidor escolhe os lugares com FOR UPDATE SKIP LOCKED, então compradores concorrentes nunca esperam pelas linhas uns dos outros.

7. Gargalos, modos de falha e trade-offs

Os dois trade-offs para dizer em voz alta: consistência acima de disponibilidade para o estoque (se o banco estiver inacessível, pare de vender; nunca venda a partir de uma réplica desatualizada), e justiça e estabilidade acima de velocidade bruta (uma venda que leva 25 minutos organizados é melhor do que uma que cai no minuto 2).

8. Experimente no playground

O cenário flash-sale reproduz o pico da abertura da venda (as nossas 10:00) num desenho que começa sem sala de espera: users → lb → app → inventory-db, com os compradores chamando o payment provider (cota de 500 req/s). O perfil load dele já contém o pico — um evento roteirizado multiplica o tráfego por 20 em t = 60 s, por 90 s.

Abrir o playground completo

9. Perguntas de follow-up que o entrevistador faz

10. Rubrica de autoavaliação

Relacionados: Hands-on 6 (reservas de lugar e transações), Hands-on 7 (outbox e fila da sala de espera), Hands-on 9 (resiliência em volta do pagamento), projeto em equipe.

Como se conecta

Quais aulas este caso testa? Cada ramo é uma aula cujas ideias o design usa (azul), com os componentes da paleta em que elas aparecem (verde):

flowchart LR
    CASE(["Ticketing (BoxOffice)"]) --> PERF["Performance<br/>Little's Law admission, spike test"]:::tech
    CASE --> EDG["Edge<br/>CDN, WAF, waiting room"]:::tech
    CASE --> DB["Databases<br/>seat holds: locks, conditional updates"]:::tech
    CASE --> CAC["Caching<br/>availability cached for 1 s"]:::tech
    CASE --> CMP["Compute<br/>checkout state machine, payment adapter"]:::tech
    CASE --> MSG["Messaging<br/>outbox, order events"]:::tech
    CASE --> REL["Reliability<br/>timeouts, retries, admission control"]:::tech
    EDG -.-> k1["cdn · waf · apigw · queue"]:::comp
    DB -.-> k2["sql · scheduler"]:::comp
    CAC -.-> k3["cache"]:::comp
    CMP -.-> k4["payment"]:::comp
    MSG -.-> k5["kafka · notifications · analytics"]:::comp
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Aulas que ele testa: Borda (WAF, bots, sala de espera) · Bancos de dados — transações · Cache — modos de falha · Compute — integrações · Mensageria — padrões · Confiabilidade — padrões · Desempenho — planejamento de capacidade · Hands-on 6, 7 e 9. Componentes da paleta: cdn · waf · apigw · queue · sql · cache · kafka · scheduler · payment · notifications · analytics. Cenários: flash-sale.

Referências

• XU, A.; LAM, S. System Design Interview — An Insider's Guide, vol. 2, cap. 7 "Hotel Reservation System" (reservas, concorrência, idempotência)¹.
• KLEPPMANN, M.; RICCOMINI, C. Designing Data-Intensive Applications, 2ª ed., capítulo sobre transações (atualizações perdidas, write skew, SELECT … FOR UPDATE)².
• APIs idempotentes e chaves como usadas por provedores de pagamento³.
• Descarte de carga e tratamento de sobrecarga⁴.