Projetar um Sistema Escalável de Reserva de Ingressos para Concerto

# Plano de Design do Sistema Escalável de Reserva de Ingressos para Shows ## 1. Premissas - Região única na nuvem (ex: AWS us-east-1) com 3 Zonas de Disponibilidade (AZs); preferência por serviços gerenciados. - Catálogo (eventos, locais, mapas de assentos) é intensivo em leitura e muda com pouca frequência. - Reservas são o caminho crítico ('hot path'); pagamentos são fora do caminho crítico ('off-hot-path') via callbacks assíncronos. - "Nunca vender a mais" é um invariante rígido; indisponibilidade breve é preferível a venda dupla. - Um provedor de pagamento externo (ex: Stripe/Adyen) lida com o escopo PCI; armazenamos apenas tokens. - Tamanho médio de evento 30k assentos; pico de demanda dura minutos a ~1 hora. ## 2. Arquitetura de Alto Nível Clientes (web/mobile) → CDN (CloudFront) → API Gateway / Balanceador de Carga L7 → Autenticação de Borda (JWT) → Microsserviços sem estado no Kubernetes (EKS) em 3 AZs. Serviços principais: - **Serviço de Identidade**: cadastro, login, emissão de JWT, MFA. - **Serviço de Catálogo**: metadados de eventos, locais, mapas de assentos; otimizado para leitura. - **Serviço de Inventário/Assentos**: estado autoritativo dos assentos, retenções, reservas; a âncora de consistência. - **Serviço de Reserva**: orquestra retenção → checkout → intenção de pagamento. - **Serviço de Pagamento**: integra com o provedor, processa callbacks de webhook de forma idempotente. - **Serviço de Ingressos**: emite ingressos digitais assinados (JWT/QR) após sucesso do pagamento. - **Serviço de Notificação**: e-mail/push (SES/SNS). - **Serviço de Sala de Espera / Fila Virtual**: limita o acesso durante picos de venda. - **Worker de Expiração**: libera retenções não pagas após 10 minutos. - **Serviço Admin/Venda**: configuração de eventos, upload de mapa de assentos, agendamento de vendas. Transversais: Kafka (MSK) para eventos, Redis (ElastiCache, modo cluster) para estado quente e locks, PostgreSQL (Aurora Multi-AZ) para dados transacionais, DynamoDB para chaves de idempotência e armazenamento de ingressos, S3 para JSON/imagens de mapa de assentos, OpenSearch para busca de eventos. ## 3. Armazenamento de Dados - **Aurora PostgreSQL (Multi-AZ, 1 gravador + 2 leitores)**: eventos, usuários, reservas, pagamentos, ingressos (sistema de registro). Backup contínuo; PITR. - **Cluster Redis (Multi-AZ, com réplicas)**: estado de retenção por assento, cache de bitmap de assentos por evento, limites de taxa, tokens da sala de espera. Usado para CAS rápido em retenções. - **DynamoDB**: chaves de idempotência de pagamento, deduplicação de webhook, consulta de ingresso emitido (baixa latência, multi-AZ por padrão). - **Kafka (MSK)**: eventos de domínio (`SeatHeld`, `ReservationCreated`, `PaymentSucceeded`, `PaymentFailed`, `ReservationExpired`, `TicketIssued`). Fator de replicação 3 entre AZs. - **S3**: artefatos estáticos de mapa de assentos, PDFs de ingressos. - **CDN**: armazena em cache listas de eventos, esqueleto do mapa de assentos (não disponibilidade ao vivo). - **OpenSearch**: busca/filtragem de eventos. ## 4. Modelo de Dados Principal **eventos**(event_id PK, venue_id, name, onsale_at, status, version). **assentos**(seat_id PK, event_id, section, row, number, price_tier, status ENUM[available, held, reserved, sold], hold_id NULL, version BIGINT). Índice composto (event_id, status). Versionamento em nível de linha para bloqueio otimista. **reservas**(reservation_id PK, user_id, event_id, seat_ids[], state ENUM[pending_payment, confirmed, expired, cancelled], created_at, expires_at, payment_intent_id, idempotency_key UNIQUE). **pagamentos**(payment_id PK, reservation_id, provider_ref UNIQUE, status, amount, currency, received_at). Restrição única em provider_ref para deduplicação pelo menos uma vez. **ingressos**(ticket_id PK, reservation_id, seat_id, qr_payload, issued_at, signature). **outbox**(id, aggregate, payload, published_at) para o padrão outbox transacional → Kafka. Chaves Redis: - `event:{id}:seat:{seat_id}` → status + proprietário da retenção + TTL 600s. - `event:{id}:availability` → bitmap/HLL para contagens rápidas. - `hold:{reservation_id}` → lista de assentos, TTL 600s. ## 5. APIs Principais (REST + cabeçalhos de idempotência) - `GET /events?filters` → lista paginada (cacheável por CDN, TTL de 30s). - `GET /events/{id}` → detalhes do evento. - `GET /events/{id}/seatmap` → layout estático (cache longo). - `GET /events/{id}/availability` → disponibilidade grosseira (seções); cache de 1–5s. - `GET /events/{id}/seats?section=A` → status detalhado dos assentos (cache curto ou ao vivo). - `POST /reservations` (Idempotency-Key) → `{event_id, seat_ids[]}` → cria retenção de 10 minutos. - `GET /reservations/{id}` → estado, expires_at. - `DELETE /reservations/{id}` → usuário cancela, libera assentos. - `POST /reservations/{id}/checkout` → cria intenção de pagamento no provedor, retorna segredo do cliente. - `POST /webhooks/payments` → callback do provedor (assinado, idempotente). - `GET /tickets/{id}` → ingresso digital assinado. - Admin: `POST /events`, `POST /events/{id}/seats:bulk`, `POST /events/{id}/onsale`. ## 6. Fluxos de Requisição ### Navegação Cliente → CDN (cache hit para catálogo/mapa de assentos) → em caso de miss, API → Serviço de Catálogo → leitor Aurora / OpenSearch. Contagens de disponibilidade servidas do Redis com 1–5s de latência; estados individuais de assentos puxados ao vivo para a seção que o usuário está visualizando. ### Reserva (retenção) 1. Cliente envia `POST /reservations` com Idempotency-Key e assentos alvo. 2. API Gateway verifica token da sala de espera; limita taxa por usuário/IP. 3. Serviço de Reserva valida o status do evento e os IDs dos assentos. 4. **Adquire retenções atomicamente** via script Lua do Redis: para cada chave de assento, `SETNX` com hold_id e TTL 600s; se algum assento falhar, desfaz os bem-sucedidos e retorna 409 com assentos conflitantes. 5. Persiste a linha de reserva no Aurora no estado `pending_payment` (transação única com evento outbox). Usa bloqueio otimista nos assentos: `UPDATE seats SET status='held', hold_id=?, version=version+1 WHERE seat_id=? AND status='available'`. Aurora é a verdade durável; Redis é o guarda rápido. Ambos devem concordar. 6. Retorna a reserva com `expires_at`. p95 < 800 ms. ### Pagamento 1. Cliente chama `POST /reservations/{id}/checkout`; Serviço de Pagamento cria um PaymentIntent no provedor, armazena `provider_ref` com chave reservation_id (idempotente). 2. Cliente completa o pagamento via SDK do provedor diretamente (ficamos fora do escopo PCI). 3. Provedor envia webhook → `POST /webhooks/payments`. 4. Manipulador de Webhook: verifica assinatura → insere/atualiza em `pagamentos` usando `provider_ref` UNIQUE (dedupe). Usa put condicional do DynamoDB na event_id para idempotência extra. 5. Em caso de `succeeded`: atualização transacional — reserva→`confirmed`, assentos→`sold`, escreve `ingressos`, anexa evento outbox `TicketIssued`. Segurança contra ordem incorreta: o manipulador compara os timestamps dos eventos e ignora transições desatualizadas (máquina de estados: pending → confirmed/failed/expired, estados terminais absorvem duplicatas tardias). 6. Serviço de Ingressos consome `TicketIssued`, gera QR/PDF assinado, armazena em S3 + DynamoDB; Serviço de Notificação envia e-mail ao usuário. ### Expiração - Primário: TTL do Redis expira a chave `hold:*` → notificação de keyspace aciona o worker de expiração; o worker executa a transação Aurora liberando os assentos apenas se a reserva ainda estiver `pending_payment` (CAS no estado). - Backstop: trabalho agendado a cada 30s escaneia `reservas WHERE state='pending_payment' AND expires_at < now() - 30s` e libera. Webhook tardio chegando após expiração: se o assento já foi revendido, marca o pagamento como `refund_required` e aciona reembolso automático; se o assento ainda estiver livre, opcionalmente reconfirma — mas a política padrão é reembolso, pois não podemos reter um assento possivelmente revendido. O atraso de 5 minutos do provedor de pagamento está dentro da janela de retenção de 10 minutos, então o caso normal não tem conflito. ## 7. Prevenção de Venda Excessiva (Consistência) - Assento é um recurso único e de propriedade: toda transição de estado usa **concorrência otimista** no Aurora (`WHERE status=expected_status AND version=expected_version`). - `SETNX` do Redis fornece rejeição de primeira linha rápida a 8k RPS sem sobrecarregar o banco de dados; a atualização da linha Aurora é a segunda linha e a verdade legal. - Todas as escritas do lado do pagamento são idempotentes via exclusividade de `provider_ref` + tabela de deduplicação do DynamoDB. - Padrão Outbox garante que eventos de domínio sejam publicados exatamente uma vez para o Kafka em relação aos commits do banco de dados. - Consistência forte dentro de uma única linha de assento; consistência eventual é aceitável apenas para contagens de disponibilidade agregadas exibidas nas visualizações de navegação. ## 8. Estratégia de Escalabilidade para Picos - **Sala de espera virtual**: quando `concurrent_users > threshold`, novos usuários recebem um token de fila; apenas N tokens/seg são admitidos nos endpoints de reserva. Mantém o sistema em capacidade conhecida (ex: admite 10k/seg para absorver 8k tentativas de reserva/seg). - **Escalabilidade horizontal automática** (HPA no EKS) em CPU e métricas personalizadas de RPS; pré-aquece pods 15 minutos antes das vendas anunciadas. - **Particionamento de eventos quentes**: particiona chaves Redis por `event_id` para que um único mega-evento caia em um shard dedicado; pode pré-provisionar shards para vendas conhecidas. - **Escalabilidade de leitura**: réplicas de leitura Aurora + Redis para disponibilidade + CDN para dados estáticos do mapa de assentos. - **Backpressure**: cotas de requisição do API Gateway por usuário; 429 com Retry-After. - **Fan-out assíncrono**: Kafka desacopla a geração de ingressos, e-mail, analytics do caminho crítico. - **Pool de conexões**: RDS Proxy / PgBouncer para evitar tempestades de conexões Aurora. - **Defesa contra bots**: WAF, CAPTCHA em `POST /reservations` durante vendas, impressão digital do dispositivo. ## 9. Confiabilidade e Recuperação de Desastres - Multi-AZ para todos os componentes com estado (Aurora, Redis com réplicas + failover automático, MSK RF=3, DynamoDB). - Aurora: backup contínuo para S3, PITR para qualquer segundo dentro da retenção → RPO ≤ 1 min atendido; failover ~30–60s → RTO ≤ 15 min atendido. - Redis: Multi-AZ com failover automático; os dados são reconstrutíveis a partir do Aurora (retenções podem ser reconstruídas em cold start a partir de `reservations WHERE state='pending_payment'`). - Kafka: armazenamento em camadas, RF=3, min ISR=2. - Runbook de DR: réplica de banco de dados global Aurora entre regiões (RPO ~ segundos) para recuperação de falhas em toda a região; procedimento de promoção documentado. - Testes de caos: apagão de AZ, kill do primário do Redis, simulação de interrupção do provedor de pagamento trimestralmente. - Verificações de integridade no nível do ALB; disjuntores (semelhantes a Resilience4j) entre serviços e em direção ao provedor de pagamento. - Degradação graciosa: se o Redis estiver indisponível, retorne ao caminho apenas com banco de dados com limite de taxa mais rigoroso; se o provedor de pagamento estiver inativo, enfileire checkouts e notifique o usuário. ## 10. Monitoramento e Alertas - **Métricas (Prometheus + CloudWatch)**: RPS, latência p50/p95/p99 por endpoint, taxa de sucesso de reserva, taxa de conflito de aquisição de retenção, atraso do webhook de pagamento, atraso do worker de expiração, atraso da réplica Aurora, CPU/memória/evicções do Redis, atraso do consumidor Kafka. - **SLOs**: disponibilidade de 99,95% na janela de venda; navegação p95 < 300 ms; reserva p95 < 800 ms; alertas de queima de orçamento de erro. - **Rastreamento**: OpenTelemetry ponta a ponta (cliente → API → serviço → DB). - **Logs**: JSON estruturado para CloudWatch/Elastic; IDs de correlação. - **Dashboards de negócios**: retenções/seg, conversão (retenção→pago), contador de venda excessiva (deve ser 0 — alerta em qualquer valor não zero). - **Alertas**: violação de oversell=0 (P0), backlog de webhook > 1 min, reserva p95 > 800 ms por 5 min, failover Aurora, failover Redis, queda na taxa de sucesso de pagamento > 2σ. ## 11. Principais Compromissos e Alternativas - **Redis como autoridade de retenção vs. apenas banco de dados**: a abordagem puramente de banco de dados é mais simples e forte, mas não conseguiria sustentar 8k RPS em hotspots de linha única; o Redis na frente absorve o pico, a atualização da linha Aurora garante a correção. - **Locks pessimistas (SELECT FOR UPDATE)**: considerado; rejeitado porque a contenção de locks em seções populares reduziria drasticamente a taxa de transferência. Bloqueio otimista com novas tentativas escala melhor. - **Assentos reservados vs. ingresso geral com contador**: o design acima é por assento. Para ingresso geral, usa-se um único contador decrescente (`DECR` no Redis com piso 0, espelhado no DB) em vez disso. - **Região única vs. ativo-ativo multi-região**: a restrição diz uma região. Ativo-ativo complicaria o "nunca vender a mais" (seria necessária consenso entre regiões). Usamos réplica de leitura entre regiões apenas para DR. - **Kafka vs. SQS**: Kafka escolhido para log de eventos ordenado e reproduzível (ajuda no processamento de pagamentos fora de ordem e na reconstrução do estado). - **Pagamento síncrono vs. apenas webhook**: apenas webhook escolhido para permanecer leve em PCI e tolerar a latência do provedor; atrasos de webhook de até 5 minutos ainda se encaixam na retenção de 10 minutos. - **Sala de espera vs. escalabilidade automática pura**: a escalabilidade automática sozinha não consegue proteger os armazenamentos com estado downstream; a fila oferece formato de carga determinístico e uma melhor experiência do usuário do que 503s em massa. - **Emissão de ingressos síncrona vs. assíncrona**: assíncrona via Kafka mantém o manipulador de callback de pagamento rápido e resiliente; o usuário vê o ingresso em segundos via push/refresh. Este design atende aos SLOs declarados, evita vendas excessivas por meio de concorrência otimista em camadas, absorve picos de vendas por meio de fila virtual + retenções com front-end Redis e atende às metas de RPO/RTO por meio de lojas gerenciadas Multi-AZ com PITR e failover ensaiado.

## Design de Sistema: Sistema Escalável de Reserva de Ingressos para Shows ### 1. Principais Serviços e Armazenamentos de Dados **Serviços:** * **API Gateway:** Ponto de entrada para todas as requisições de clientes, lida com autenticação, limitação de taxa e roteamento de requisições. * **Serviço de Usuário:** Gerencia registro de usuários, perfis e autenticação. * **Serviço de Eventos:** Gerencia detalhes de eventos, cronogramas e conteúdo estático. * **Serviço de Assentos:** Gerencia inventário de assentos, disponibilidade e dados do mapa de assentos para eventos. * **Serviço de Reserva:** Lida com a lógica de reserva de assentos, gerencia ciclos de vida de reserva (pendente, confirmada, expirada). * **Serviço de Pagamento (Interno):** Orquestra interações com provedores de pagamento externos, processa callbacks e gerencia registros de pagamento internos. * **Serviço de Notificação:** Envia ingressos digitais, e-mails de confirmação e outras notificações ao usuário. * **Serviço de Fila (Kafka):** Comunicação assíncrona entre serviços, lida com eventos de alta vazão (por exemplo, callbacks de pagamento, expiração de reserva). * **Serviço de Cache (Redis):** Acesso a dados de alta velocidade para disponibilidade de assentos, detalhes de eventos e locks distribuídos. * **Serviço de Worker em Background:** Processa tarefas assíncronas como expiração de reserva, retentativas de callback de pagamento e limpeza de dados. **Armazenamentos de Dados:** * **PostgreSQL (Banco de Dados Relacional):** Armazenamento de dados primário para usuários, eventos, assentos, reservas e pagamentos. Escolhido por suas fortes propriedades ACID, cruciais para evitar overselling. * *Implantação:* Configuração multi-AZ, primário-réplica com replicação síncrona para tabelas críticas (assentos, reservas) e assíncrona para outras. * **Redis (Armazenamento em Memória):** Usado para: * Cache de disponibilidade de assentos e detalhes de eventos. * Locks distribuídos para reserva e confirmação de assentos. * Timers temporários de expiração de reserva (chaves TTL). * **Kafka (Plataforma de Streaming Distribuído):** Para passagem de mensagens confiável e assíncrona e event sourcing. * **Armazenamento de Objetos (por exemplo, S3):** Armazena ativos estáticos como imagens de eventos, fotos de artistas e potencialmente PDFs de ingressos digitais. ### 2. APIs Principais **Serviço de Usuário:** * `POST /users/register`: Registrar um novo usuário. * `POST /users/login`: Autenticar usuário. * `GET /users/{id}`: Recuperar perfil do usuário. **Serviço de Eventos:** * `GET /events`: Navegar por todos os eventos (paginado). * `GET /events/{id}`: Recuperar detalhes de um evento específico. * `GET /events/{id}/seatmap`: Recuperar mapa de assentos e disponibilidade atual para um evento. **Serviço de Reserva:** * `POST /events/{id}/reserve`: Reservar assentos específicos para um evento. Entrada: `event_id`, `seat_ids`, `user_id`. Saída: `reservation_id`, `expires_at`. * `GET /reservations/{id}`: Recuperar detalhes da reserva. * `DELETE /reservations/{id}`: Cancelar uma reserva pendente. * `POST /reservations/{id}/confirm`: Confirmar uma reserva após pagamento bem-sucedido (API interna, acionada pelo Serviço de Pagamento). **Serviço de Pagamento:** * `POST /payments/initiate`: Iniciar pagamento para uma reserva. Entrada: `reservation_id`, `amount`, `user_id`. Saída: URL de redirecionamento do provedor de pagamento. * `POST /payments/callback`: Endpoint de webhook para callbacks de provedores de pagamento externos (interno). **Serviço de Ingressos (parte do Serviço de Notificação/Reserva):** * `GET /tickets/{id}`: Recuperar um ingresso digital. ### 3. Modelo de Dados para Assentos e Reservas **Tabela: `users`** * `user_id` (PK, UUID) * `username` (VARCHAR, UNIQUE) * `email` (VARCHAR, UNIQUE) * `password_hash` (VARCHAR) * `created_at` (TIMESTAMP) **Tabela: `events`** * `event_id` (PK, UUID) * `name` (VARCHAR) * `venue` (VARCHAR) * `date_time` (TIMESTAMP) * `total_seats` (INT) * `image_url` (VARCHAR) **Tabela: `seats`** * `seat_id` (PK, UUID) * `event_id` (FK para `events.event_id`) * `section` (VARCHAR) * `row_number` (VARCHAR) * `seat_number` (VARCHAR) * `price` (DECIMAL) * `status` (ENUM: 'available', 'reserved', 'sold') * `version` (INT, para locking otimista) **Tabela: `reservations`** * `reservation_id` (PK, UUID) * `user_id` (FK para `users.user_id`) * `event_id` (FK para `events.event_id`) * `status` (ENUM: 'pending', 'confirmed', 'expired', 'cancelled') * `reserved_at` (TIMESTAMP) * `expires_at` (TIMESTAMP) * `payment_id` (FK para `payments.payment_id`, nullable) * `total_amount` (DECIMAL) * `created_at` (TIMESTAMP) * `updated_at` (TIMESTAMP) **Tabela: `reservation_seats` (Tabela de Junção)** * `reservation_id` (FK para `reservations.reservation_id`) * `seat_id` (FK para `seats.seat_id`) * (PK Composta: `reservation_id`, `seat_id`) **Tabela: `payments`** * `payment_id` (PK, UUID) * `reservation_id` (FK para `reservations.reservation_id`) * `user_id` (FK para `users.user_id`) * `amount` (DECIMAL) * `currency` (VARCHAR) * `provider_transaction_id` (VARCHAR, UNIQUE) * `status` (ENUM: 'initiated', 'pending', 'succeeded', 'failed', 'refunded') * `created_at` (TIMESTAMP) * `updated_at` (TIMESTAMP) ### 4. Fluxo de Requisição **A. Navegando por Eventos e Visualizando Disponibilidade de Assentos:** 1. **Requisição do Usuário:** Navegador/aplicativo do usuário solicita `/events` ou `/events/{id}/seatmap`. 2. **CDN:** Serve ativos estáticos (imagens de eventos, JS/CSS) se em cache. 3. **API Gateway:** Autentica o usuário, roteia a requisição para o Serviço de Eventos ou Serviço de Assentos. 4. **Serviço de Eventos:** Recupera detalhes do evento do PostgreSQL (ou cache Redis). 5. **Serviço de Assentos:** Recupera o mapa de assentos e a disponibilidade do cache Redis. Se não estiver em cache, consulta a tabela `seats` do PostgreSQL, atualiza o cache e retorna os dados. 6. **Resposta:** Dados retornados ao usuário. (Latência P95 < 300 ms). **B. Reservando Assentos:** 1. **Requisição do Usuário:** Usuário seleciona assentos e clica em 'Reservar', enviando `POST /events/{id}/reserve` com `event_id`, `seat_ids`, `user_id`. 2. **API Gateway:** Roteia para o Serviço de Reserva. 3. **Serviço de Reserva:** * **Lock Distribuído:** Adquire um lock distribuído no Redis para cada `seat_id` para evitar modificações concorrentes. (por exemplo, `LOCK:seat:{seat_id}`). * **Verificação de Status do Assento:** Consulta a tabela `seats` (ou cache Redis) para verificar se os assentos selecionados estão 'available'. * **Transação:** Inicia uma transação no banco de dados. * **Atualiza Assentos:** Atualiza o `status` dos assentos selecionados para 'reserved' na tabela `seats`. * **Cria Reserva:** Insere um novo registro na tabela `reservations` com `status='pending'`, `reserved_at` e `expires_at` (tempo atual + 10 minutos). * **Vincula Assentos:** Insere registros em `reservation_seats` para cada assento reservado. * **Confirma Transação.** * **Define TTL no Redis:** Define uma chave Redis (por exemplo, `RESERVATION_EXPIRY:{reservation_id}`) com um TTL de 10 minutos. Isso atua como um gatilho de expiração de caminho rápido. * **Libera Locks:** Libera os locks distribuídos para os assentos. 4. **Resposta:** Retorna `reservation_id` e `expires_at` ao usuário. (Latência P95 < 800 ms, excluindo pagamento). **C. Pagando pela Reserva:** 1. **Ação do Usuário:** Usuário inicia o pagamento de uma reserva `pending`. 2. **Requisição do Usuário:** Navegador/aplicativo envia `POST /payments/initiate` com `reservation_id` para o Serviço de Pagamento. 3. **Serviço de Pagamento (Interno):** * Cria um registro de `payment` com `status='initiated'`. * Chama a API do Provedor de Pagamento externo (por exemplo, Stripe, PayPal) com os detalhes da reserva e o valor. * Redireciona o usuário para a página do Provedor de Pagamento. 4. **Provedor de Pagamento Externo:** Processa o pagamento. 5. **Callback do Provedor de Pagamento:** Após pagamento bem-sucedido/falho, o provedor externo envia um webhook assíncrono `POST /payments/callback` para o Serviço de Pagamento. 6. **Serviço de Pagamento (Interno) - Manipulador de Callback:** * **Verificação de Idempotência:** Usa `provider_transaction_id` para garantir que o callback seja processado apenas uma vez. * Atualiza o status do registro `payment` (`succeeded` ou `failed`). * Publica um evento `PaymentConfirmed` ou `PaymentFailed` no Kafka, incluindo `reservation_id` e `payment_id`. 7. **Serviço de Reserva - Consumidor Kafka:** * Consome o evento `PaymentConfirmed`. * **Lock Distribuído:** Adquire um lock para o `reservation_id`. * **Transação:** Inicia uma transação no banco de dados. * **Atualiza Reserva:** Atualiza a tabela `reservations`: `status='confirmed'`, vincula `payment_id`. * **Atualiza Assentos:** Atualiza o `status` dos assentos associados na tabela `seats` para 'sold'. * **Confirma Transação.** * **Remove TTL do Redis:** Exclui a chave `RESERVATION_EXPIRY:{reservation_id}` do Redis. * **Libera Lock.** * Publica um evento `TicketIssued` no Kafka. 8. **Serviço de Notificação - Consumidor Kafka:** Consome o evento `TicketIssued`, gera o ingresso digital e envia e-mail/notificação push para o usuário. **D. Expirando Reservas:** 1. **Eventos Keyspace do Redis / Worker em Background:** * **Caminho Rápido (TTL do Redis):** Quando uma chave `RESERVATION_EXPIRY:{reservation_id}` expira no Redis, um evento keyspace é acionado. Um microserviço dedicado ou worker em background consome este evento. * **Caminho Robusto (Scan do DB):** Um Serviço de Worker em Background periodicamente (por exemplo, a cada 30 segundos) escaneia a tabela `reservations` em busca de registros onde `status='pending'` e `expires_at < tempo_atual`. 2. **Lógica do Worker em Background:** * Para cada reserva `pending` expirada: * **Lock Distribuído:** Adquire um lock para o `reservation_id`. * **Verifica Status:** Verifica se a reserva ainda está `pending` (para evitar expirar reservas já pagas devido a condições de corrida ou eventos atrasados). * **Transação:** Inicia uma transação no banco de dados. * **Atualiza Reserva:** Atualiza a tabela `reservations`: `status='expired'`. * **Atualiza Assentos:** Atualiza o `status` dos assentos associados na tabela `seats` de volta para 'available'. * **Confirma Transação.** * **Libera Lock.** ### 5. Estratégia de Escalabilidade para Picos de Tráfego * **Serviços Stateless:** Todos os serviços de aplicação (Usuário, Evento, Assento, Reserva, Pagamento, Notificação) são projetados para serem stateless, permitindo escalabilidade horizontal. * **Grupos de Auto-Escalabilidade (ASG):** Os serviços são implantados em ASGs que adicionam/removem instâncias automaticamente com base em métricas como utilização de CPU, profundidade da fila de requisições ou métricas personalizadas (por exemplo, reservas ativas). * **Balanceadores de Carga:** Balanceadores de Carga de Aplicação (ALBs) distribuem o tráfego de entrada entre instâncias saudáveis de cada serviço em múltiplas Zonas de Disponibilidade. * **CDN:** Rede de Entrega de Conteúdo (CDN) armazena em cache ativos estáticos (imagens de eventos, JS, CSS) para descarregar tráfego dos serviços de backend e reduzir a latência para os usuários. * **Cache (Redis):** Uso extensivo de Redis para cache de dados acessados com frequência (disponibilidade de assentos, detalhes de eventos) reduz significativamente a carga do banco de dados, especialmente durante visualizações de navegação e mapas de assentos com muitas leituras. * **Filas (Kafka):** Kafka atua como um buffer, desacoplando serviços e absorvendo picos de tráfego. Operações assíncronas (callbacks de pagamento, notificações, processamento de expiração de reserva) são enviadas para o Kafka, permitindo que os serviços as processem em seu próprio ritmo sem bloquear as requisições do usuário. * **Réplicas de Leitura do Banco de Dados:** Instâncias PostgreSQL são configuradas com múltiplas réplicas de leitura. Serviços com muitas leituras (Serviço de Eventos, Serviço de Assentos para mapas de assentos) podem direcionar suas consultas para essas réplicas, descarregando o banco de dados primário. * **Sharding do Banco de Dados (Futuro Potencial):** Se uma única instância PostgreSQL se tornar um gargalo para escritas, o sharding por `event_id` ou `user_id` pode ser considerado. Isso envolveria a distribuição de dados entre múltiplas instâncias de banco de dados. * **Pool de Conexões:** Gerenciamento eficiente de conexões de banco de dados para minimizar sobrecarga e maximizar a vazão. * **Limitação de Taxa:** Implementada no API Gateway para proteger os serviços de backend contra tráfego abusivo ou picos repentinos e avassaladores. ### 6. Abordagem de Confiabilidade e Recuperação de Desastres * **Implantação Multi-Zona de Disponibilidade (Multi-AZ):** Todos os serviços e armazenamentos de dados são implantados em pelo menos três Zonas de Disponibilidade dentro da região da nuvem. Isso fornece resiliência contra falhas em nível de AZ. * **Replicação e Failover do Banco de Dados:** * **PostgreSQL:** Configuração primário-réplica. Dados críticos (assentos, reservas) usam replicação síncrona para garantir RPO < 1 minuto. Mecanismos de failover automatizados (por exemplo, Patroni, failover gerenciado pela nuvem RDS) promovem uma réplica para primária em caso de falha da primária, alcançando RTO < 15 minutos. * **Redis:** Modo Sentinel ou Cluster para alta disponibilidade, com dados replicados entre nós em diferentes AZs. * **Durabilidade do Kafka:** Brokers Kafka são implantados em múltiplas AZs com fator de replicação > 1 (por exemplo, 3) para garantir a durabilidade das mensagens e a disponibilidade mesmo que uma AZ ou broker falhe. * **Backups Automatizados:** Backups regulares e automatizados do PostgreSQL para armazenamento de objetos com capacidades de recuperação point-in-time. Snapshots para Redis. * **Serviços Stateless:** Serviços são projetados para serem stateless, o que significa que qualquer instância pode ser substituída ou reiniciada sem perda de dados, contribuindo para alta disponibilidade. * **Circuit Breakers e Retentativas:** Implementados na comunicação serviço-a-serviço para evitar falhas em cascata. Os serviços degradarão graciosamente ou tentarão novamente as requisições falhas. * **Degradação Graciosa:** Durante carga extrema, recursos não críticos (por exemplo, recomendações personalizadas) podem ser temporariamente desativados para priorizar a funcionalidade principal (reserva, pagamento). * **Objetivo de Ponto de Recuperação (RPO) < 1 minuto:** Alcançado por replicação síncrona do banco de dados para dados críticos e registro durável de mensagens do Kafka com configurações de replicação apropriadas. * **Objetivo de Tempo de Recuperação (RTO) < 15 minutos:** Alcançado por failover automatizado do banco de dados, auto-escalabilidade dos serviços de aplicação e instâncias pré-aquecidas ou capacidades de provisionamento rápido. ### 7. Escolhas de Consistência que Evitam Overselling Evitar overselling é fundamental e requer forte consistência para atualizações de status de assentos. * **Locks Distribuídos (Redis):** Quando um usuário tenta reservar assentos, o Serviço de Reserva adquire um lock distribuído para cada `seat_id` específico no Redis. Isso garante que apenas uma tentativa de reserva possa modificar o status de um determinado assento a qualquer momento. O lock é mantido durante a transação do banco de dados que atualiza o status do assento e cria a reserva. * **Transações ACID (PostgreSQL):** Todas as atualizações do status de `seats` e a criação/atualização de registros de `reservations` são realizadas dentro de uma única transação ACID no PostgreSQL. Isso garante atomicidade, consistência, isolamento e durabilidade. Se qualquer parte da transação falhar (por exemplo, outro usuário já reservou um assento), toda a transação é revertida, garantindo que não haja atualizações parciais e evitando overselling. * **Controle de Concorrência Otimista (Números de Versão):** Para a tabela `seats`, uma coluna `version` pode ser adicionada. Ao atualizar o status de um assento, a consulta `UPDATE` inclui um `WHERE version = <old_version>`. Se a versão não corresponder, significa que outra transação modificou o assento, e a transação atual pode ser retentada ou rejeitada. Isso fornece uma camada adicional de proteção contra condições de corrida, especialmente se os locks distribuídos falharem ou não forem implementados perfeitamente. * **Processamento de Pagamento Idempotente:** Callbacks do provedor de pagamento são `at-least-once` e podem estar fora de ordem. O Serviço de Pagamento processa esses callbacks de forma idempotente, usando o `provider_transaction_id` para garantir que um pagamento bem-sucedido seja aplicado apenas uma vez a uma reserva, evitando confirmações duplicadas ou atualizações de status incorretas. * **Lógica de Expiração de Reserva:** O processo de expiração verifica explicitamente se uma reserva ainda está `pending` antes de marcá-la como `expired` e liberar os assentos. Isso evita uma condição de corrida onde um pagamento pode chegar exatamente quando o processo de expiração está prestes a ser executado. ### 8. Monitoramento e Alerta * **Coleta de Métricas:** Use Prometheus/Grafana ou monitoramento nativo da nuvem (por exemplo, CloudWatch, Stackdriver) para coletar métricas de todos os serviços, bancos de dados, caches e filas. Métricas chave incluem: * **Métricas do Sistema:** Utilização de CPU, uso de memória, I/O de disco, I/O de rede. * **Métricas da Aplicação:** Taxas de requisição, taxas de erro (5xx), latência (p95, p99) para todos os endpoints de API, profundidades de fila, conexões ativas, coleta de lixo. * **Métricas do Banco de Dados:** Latência de consulta, uso do pool de conexões, taxas de transação, lag de replicação, deadlocks. * **Métricas de Cache:** Taxa de acerto/erro de cache, uso de memória. * **Métricas do Kafka:** Lag do produtor/consumidor, taxas de mensagens, saúde do broker. * **Logging Centralizado:** Agregue logs de todos os serviços em um sistema de logging centralizado (por exemplo, stack ELK, Splunk, Datadog). Use logging estruturado para facilitar a análise e o parsing. * **Rastreamento Distribuído:** Implemente rastreamento distribuído (por exemplo, OpenTelemetry, Jaeger) para visualizar fluxos de requisição entre múltiplos serviços, identificar gargalos e depurar interações complexas. * **Alertas:** Configure alertas para limites críticos: * Altas taxas de erro (por exemplo, 5% de erros 5xx em 5 minutos). * Alta latência (por exemplo, latência P95 da API > 800ms). * Indisponibilidade de serviço ou instâncias não saudáveis. * Lag de replicação do banco de dados excedendo limites. * Backlogs de fila. * Falhas de callback de pagamento ou expiração de reserva. * Esgotamento de recursos (CPU, memória, disco). * **Dashboards:** Crie dashboards em tempo real para visibilidade operacional, exibindo métricas chave e saúde do serviço. ### 9. Principais Trade-offs ou Alternativas * **Escolha do Banco de Dados:** * **Alternativa:** Banco de dados NoSQL (por exemplo, Cassandra, DynamoDB) para escalabilidade de escrita extrema. **Trade-off:** Embora o NoSQL possa lidar com escala massiva, alcançar forte consistência para operações transacionais complexas como reservas de assentos (que envolvem múltiplas atualizações e verificações) é significativamente mais desafiador e muitas vezes requer lógica complexa no nível da aplicação. As propriedades ACID do PostgreSQL simplificam a prevenção de overselling, e sua escalabilidade pode ser gerenciada através de réplicas de leitura e sharding. * **Mecanismo de Lock:** * **Alternativa:** Locks de linha em nível de banco de dados. **Trade-off:** Podem levar a maior contenção e potenciais deadlocks em cenários de alta concorrência, impactando o desempenho. Locks distribuídos do Redis são geralmente mais rápidos e descarregam o mecanismo de lock do banco de dados, mas requerem implementação cuidadosa (por exemplo, lidar com expiração de lock, garantir atomicidade de aquisição/liberação de lock). * **Expiração de Reserva:** * **Alternativa:** Confiar puramente em eventos keyspace do TTL do Redis. **Trade-off:** Embora rápido, os eventos keyspace do Redis não são garantidos de serem entregues (por exemplo, se o Redis reiniciar ou eventos forem perdidos). A abordagem escolhida combina TTL do Redis para um caminho rápido com um worker robusto que escaneia o banco de dados para consistência eventual, garantindo que nenhuma reserva fique permanentemente presa em `pending`. * **Tratamento de Callback de Pagamento:** * **Alternativa:** Callback síncrono do provedor de pagamento. **Trade-off:** Isso raramente é oferecido por provedores externos e exigiria que a plataforma fosse altamente disponível e responsiva ao provedor de pagamento, introduzindo acoplamento apertado. A abordagem assíncrona, `at-least-once`, via Kafka é padrão e mais resiliente, mas exige processamento idempotente e tratamento de mensagens fora de ordem. * **Microserviços vs. Monólito:** * **Alternativa:** Arquitetura monolítica. **Trade-off:** Mais simples de desenvolver inicialmente, mas mais difícil de escalar componentes individuais, implantar independentemente e gerenciar para equipes grandes. Microserviços oferecem melhor escalabilidade, isolamento de falhas e diversidade de tecnologia, mas introduzem complexidade operacional (transações distribuídas, monitoramento, implantação). ### 10. Suposições * **Autenticação de Usuário:** Usuários são autenticados antes de realizar quaisquer ações que exijam identidade (por exemplo, reservar assentos, visualizar ingressos). * **Conformidade PCI:** O provedor de pagamento externo lida com todos os requisitos de conformidade PCI DSS; o Serviço de Pagamento interno apenas orquestra e armazena dados de pagamento mínimos e não sensíveis. * **Capacidade da Região da Nuvem:** A região da nuvem escolhida tem capacidade de computação, rede e armazenamento suficiente para lidar com as cargas de pico especificadas. * **Latência de Rede:** A latência da rede interna dentro da região da nuvem e entre as Zonas de Disponibilidade é baixa o suficiente para atender às metas de latência. * **Segurança:** Práticas de segurança padrão (por exemplo, criptografia em trânsito e em repouso, validação de entrada, controle de acesso, varredura de vulnerabilidades) são implementadas em todo o sistema, embora não detalhadas neste design. * **Confiabilidade do Provedor de Pagamento Externo:** Assume-se que o provedor de pagamento externo seja altamente disponível e confiável para processar pagamentos e enviar callbacks.