Você clicou em Comprar.
E agora?

O que acontece tecnicamente depois que você clica em Comprar?

POST /orders

{
  "productId": "prod_123",
  "quantity": 1
}

Um clique. Um POST. Um banco.

const order = await createOrder(input);

return {
  id: order.id,
  status: "PENDING"
};

O cliente espera só o caminho crítico do request.

ACID é o contrato do banco — não de todo o sistema distribuído.

BEGIN;

INSERT INTO orders (...);
INSERT INTO order_items (...);

COMMIT;

Cobrar. Reservar. Checar. Avisar. Medir.

Novas responsabilidades. Mesmo request. Novo risco.

await createOrder();
await chargePayment();
await reserveInventory();
await runFraudCheck();
await sendEmail();
await trackAnalytics();

TOTAL > 1s  ·  o usuário espera tudo

Cada await no caminho crítico é tempo na cara do usuário.

Se não queremos esperar tudo, o que muda no modelo do request?

Async não apaga o trabalho. Muda quando ele acontece.

Sem transação global, o pedido vira uma máquina de estados.

SELECT
  DATE(created_at),
  product_id,
  SUM(total)
FROM orders
WHERE created_at >= NOW() - INTERVAL '1 year'
GROUP BY 1, 2;

500M rows scanned.

O checkout acabou de competir com o dashboard.

Mesmos dados. Workloads completamente diferentes.

A ordem de Transform e Load muda quem paga a complexidade.

Real-time sobe complexity, cost e operational burden.

Se o Order Service não deve conhecer cada sistema, como distribuímos a informação?

Producer doesn't need to know every consumer.

{
  "eventId": "evt_01J...",
  "type": "OrderCreated",
  "version": 1,
  "occurredAt": "2026-09-01T18:00:00Z",
  "data": {
    "orderId": "ord_987",
    "customerId": "usr_42",
    "total": 249.90
  }
}

Um evento é um fato versionado — não um dump da tabela.

Kafka não é uma fila tradicional. É um log distribuído.

Ordem existe — mas o escopo importa.

partition key = orderId

Um grupo escala partições. Grupos diferentes não roubam mensagens uns dos outros.

Mesmo tópico. Offsets independentes por consumer group.

There is no universal winner.

SQS não é “Kafka simples”. São modelos diferentes.

At-least-once + idempotency. Esse é o combo prático.

Retries resolvem falhas transitórias. E criam um problema novo.

Idempotency-Key: order_987

// gateway de pagamento
// mesma chave = mesma cobrança

processed_events
  event_id     PK
  processed_at

// se event_id existe → skip

Chave de idempotência no provedor. Ou tabela local de eventos processados. Ou os dois.

Retrying is easy. Retrying safely is hard.

Backoff protege o destino. Não é só cortesia.

1s → 2s → 4s → 8s

Poison message: nunca vai passar. Retry infinito é um loop de CPU e custo.

Conseguimos entregar eventos. Como garantir que o evento exista sempre que o pedido existir?

await db.orders.insert(order);

await kafka.publish({
  type: "OrderCreated",
  orderId: order.id
});

Two writes. Two systems. No shared transaction.

BEGIN;
  INSERT orders
  INSERT outbox_events
COMMIT;

Persist the change and the intent to publish together.

Publisher lê unpublished, envia, marca published_at. Crash? Lê de novo.

Observe changes instead of repeatedly asking for them.

Agora temos um histórico de eventos. Como viram informação para o negócio?

Common pattern, not a universal rule.

Operational models answer transactions. Analytical models answer questions.

Lake não substitui warehouse — são camadas com jobs diferentes.

Fact = métrica. Dimension = contexto.

SELECT
  order_id,
  customer_id,
  total
FROM {{ ref('stg_orders') }}
WHERE status = 'PAID'

Transformações versionadas. Lineage legível.

Data quality starts at the source.

// ANTES
{ "status": "paid" }

// DEPOIS
{ "status": "completed" }

Your event is an API.

Compatibilidade é disciplina — não acidente.

A arquitetura funciona. Quando algo quebra, como descobrimos onde?

Um pedido desapareceu. Onde ele está?

If an order disappears, can we trace its journey?

Atraso de convergência ≠ bug automático.

Clique um card · R revela o próximo

Cada caixa existe por um problema que já vimos.

Marketplace · 5M usuários · 500k pedidos/dia

Checkout · Payment · Inventory · Fraud · Notifications · Near-real-time analytics

Clique ou R — uma de cada vez.