Projetando o iFood em Escala Nacional: Guia Completo de System Design

Diagramas utlizados disponíveis no link https://link.excalidraw.com/l/7XRBb57RGJp/AtcIsUy9BEw

Às 12:06, um usuário em São Paulo faz pedido de almoço. Nos próximos 10 minutos, milhares de usuários na mesma região fazem pedidos parecidos.

Ao mesmo tempo:

• cozinhas entram em carga máxima,
• disponibilidade de entregador oscila por bairro,
• chuva muda velocidade média,
• retries de pagamento aumentam por rede móvel instável.

A UX esperada continua simples:

• buscar,
• escolher,
• pagar,
• acompanhar,
• receber.

No backend, isso é orquestração distribuída com múltiplos atores:

• cliente,
• restaurante,
• entregador,
• processador de pagamento,
• provedor de mapas/rotas,
• suporte/fraude.

Esse artigo foca no que realmente quebra em escala e como desenhar para evitar.

Sumário

• Análise de Requisitos
• Cálculos de Envelope
• Arquitetura de Alto Nível
• Design de API
• Modelagem de Dados
• Discovery e Busca de Marketplace (Core 1)
• Checkout e Criação de Pedido (Core 2)
• Dispatch e Matching de Entregador (Core 3)
• Rastreamento em Tempo Real (Core 4)
• Predição de ETA e Promise Engine (Core 5)
• Taxas, Precificação e Surge (Core 6)
• Pagamento e Settlement (Core 7)
• Cancelamento, Reembolso e Compensação (Core 8)
• Operação de Restaurante e Capacidade
• Notificações e Comunicação
• Caching e Sharding
• Arquitetura Event-Driven
• Multi-Região e Disaster Recovery
• Segurança, Fraude e Abuse
• Observabilidade e SLOs
• Dicas de Entrevista
• Anti-Patterns
• Conclusão
• Referências
• Referência Rápida

Análise de Requisitos

Requisitos Funcionais

Cliente

1. Descobrir restaurantes por localização.
2. Buscar por categoria, prato e palavra-chave.
3. Ver menu, preço, status e taxa de entrega.
4. Montar carrinho com customizações.
5. Aplicar cupom e pagar.
6. Acompanhar status e localização do entregador.
7. Cancelar dentro de regras.
8. Abrir suporte e avaliar.

Restaurante

1. Gerenciar menu e indisponibilidade de item.
2. Configurar tempo de preparo e capacidade.
3. Aceitar/recusar pedidos.
4. Atualizar status de preparo.

Entregador

1. Receber ofertas de corrida.
2. Aceitar pickup/delivery.
3. Enviar localização periódica.
4. Atualizar milestones da entrega.

Requisitos Não-Funcionais

Modelo de Consistência

• Forte para criação de pedido e transições financeiras.
• Eventual para ranking/discovery.
• Near-real-time eventual para tracking/ETA.

Perguntas de Clarificação

1. Escopo só food ou food + grocery?
2. Frota própria ou mista?
3. Cash-on-delivery incluso?
4. Escala por cidade ou nacional?
5. SLA esperado de ETA?

Premissas:

• food delivery nacional,
• pagamento digital principal,
• tracking em tempo real obrigatório,
• despacho como diferencial crítico.

Cálculos de Envelope

Escala Assumida

DAU: 35 milhões
Pedidos/dia: 12 milhões
Restaurantes ativos: 450 mil
Entregadores ativos/dia: 1,2 milhão
Location ping: 1 a cada 3s quando ativo
Pico almoço/jantar: 8x média

Throughput

Pedidos/s medio = 12.000.000 / 86.400 ~= 139
Pico ~= 1.112 pedidos/s

Checkout req/s medio ~= 520
Pico ~= 4.160

Discovery req/s medio ~= 34.722
Pico ~= 208.332

Ingestão de Localização

Assumindo 450 mil entregadores ativos simultâneos em pico:

pings/s = 450.000 / 3 ~= 150.000
payload médio 120B => ~18MB/s (+ overhead)

Armazenamento Direcional

order row ~4KB => 12M/dia ~= 48GB/dia
order events ~600B * 240M ~= 144GB/dia
trilha de localização amostrada ~= 100GB+/dia

Insight

Três caminhos dominam arquitetura:

1. leitura de marketplace,
2. consistencia de pedido/pagamento,
3. realtime de dispatch/tracking.

Arquitetura de Alto Nível

Princípios

1. Isolar caminho read-heavy de marketplace.
2. Proteger caminho transacional de pedido.
3. Separar pipeline realtime de tracking.
4. Modelar compensações explícitas.

Design de API

Cliente

GET /v1/restaurants?lat={lat}&lng={lng}&page=1
GET /v1/restaurants/{id}/menu
POST /v1/carts/{cart_id}/items
PATCH /v1/carts/{cart_id}/items/{item_id}
POST /v1/checkout/preview
POST /v1/checkout/submit
GET /v1/orders/{order_id}
GET /v1/orders/{order_id}/tracking
POST /v1/orders/{order_id}/cancel

Restaurante

PATCH /v1/restaurants/{id}/availability
PATCH /v1/orders/{order_id}/status
POST /v1/menus/{menu_id}/items
PATCH /v1/menus/{menu_id}/items/{item_id}

Entregador

GET /v1/courier/tasks/next
POST /v1/courier/tasks/{task_id}/accept
POST /v1/courier/tasks/{task_id}/status
POST /v1/courier/location

Checkout Submit

{
  "idempotency_key": "0d6e3d13-cbe3-42ec-bbd4-b7f5f2b57a0c",
  "customer_id": "cust_321",
  "cart_id": "cart_99",
  "delivery_address_id": "addr_777",
  "payment_method_id": "pm_abc",
  "tip_cents": 500,
  "coupon_code": "ALMOCO10",
  "client_context": {
    "device_id": "ios_55",
    "ip": "198.51.100.20",
    "app_version": "8.14.2"
  }
}

Idempotency

CREATE TABLE idempotency_records (
  idempotency_key VARCHAR(64) NOT NULL,
  customer_id BIGINT NOT NULL,
  request_hash CHAR(64) NOT NULL,
  response_code INT NOT NULL,
  response_body JSONB NOT NULL,
  created_at TIMESTAMP NOT NULL,
  expires_at TIMESTAMP NOT NULL,
  PRIMARY KEY (idempotency_key, customer_id)
);

Modelagem de Dados

Entidades

1. Customer
2. Restaurant
3. MenuItem
4. Cart
5. Order
6. OrderItem
7. PaymentAttempt
8. DispatchTask
9. Courier
10. CourierLocationPing
11. Refund

Schema de Pedido

CREATE TABLE orders (
  order_id BIGSERIAL PRIMARY KEY,
  customer_id BIGINT NOT NULL,
  restaurant_id BIGINT NOT NULL,
  courier_id BIGINT,
  status VARCHAR(32) NOT NULL,
  subtotal_cents BIGINT NOT NULL,
  delivery_fee_cents BIGINT NOT NULL,
  service_fee_cents BIGINT NOT NULL,
  tip_cents BIGINT NOT NULL,
  discount_cents BIGINT NOT NULL,
  total_cents BIGINT NOT NULL,
  currency CHAR(3) NOT NULL,
  placed_at TIMESTAMP NOT NULL,
  updated_at TIMESTAMP NOT NULL,
  idempotency_key VARCHAR(64) NOT NULL,
  UNIQUE (customer_id, idempotency_key)
);

CREATE TABLE order_items (
  order_item_id BIGSERIAL PRIMARY KEY,
  order_id BIGINT NOT NULL REFERENCES orders(order_id),
  menu_item_id BIGINT NOT NULL,
  quantity INT NOT NULL,
  unit_price_cents BIGINT NOT NULL,
  customization JSONB,
  item_total_cents BIGINT NOT NULL
);

Eventos de Pedido

CREATE TABLE order_events (
  event_id BIGSERIAL PRIMARY KEY,
  order_id BIGINT NOT NULL,
  event_type VARCHAR(64) NOT NULL,
  event_payload JSONB NOT NULL,
  created_at TIMESTAMP NOT NULL
);

ER Simplificado

Discovery e Busca de Marketplace (Core 1)

Inputs de Discovery

1. localização do usuário,
2. cobertura de entrega,
3. status operacional,
4. ETA e taxa estimados,
5. ranking de relevância/conversão.

Fluxo

Features de Ranking

• CTR histórico por bairro,
• CVR por horário,
• SLA de preparo,
• taxa de cancelamento,
• qualidade de avaliação,
• distância estimada.

Checkout e Criação de Pedido (Core 2)

Etapas

1. Validar carrinho e ownership.
2. Recalcular preço/taxas.
3. Reservar slot de capacidade do restaurante.
4. Autorizar pagamento.
5. Criar pedido transacionalmente.
6. Publicar OrderPlaced.

Sequencia

Fronteiras de Transação

Evite 2PC global. Use:

• validações sincr. críticas,
• escrita transacional local de pedido,
• outbox + compensações.

Dispatch e Matching de Entregador (Core 3)

Objetivo

Balancear:

• velocidade de entrega,
• custo operacional,
• utilização de frota,
• fairness entre entregadores.

Inputs

1. local pickup/dropoff,
2. tempo de preparo,
3. posição e modo do entregador,
4. probabilidade de aceitação,
5. pressão demanda/oferta da zona.

Score de Matching (exemplo)

score =
  w1 * pickup_eta
+ w2 * dropoff_eta
+ w3 * acceptance_penalty
+ w4 * utilization_penalty
+ w5 * zone_balance_penalty

Sequencia

Reassign

Se entregador falhar:

• reassign rápido,
• recalculo de ETA,
• notificação proativa,
• política de compensação se necessário.

Rastreamento em Tempo Real (Core 4)

Payload de Ping

{
  "courier_id": "cour_887",
  "task_id": "task_552",
  "lat": -23.5601,
  "lng": -46.6552,
  "speed_mps": 6.2,
  "heading_deg": 110,
  "timestamp": "2026-02-22T12:41:10Z"
}

Pipeline

1. ingest low-latency,
2. validação e anti-spoof,
3. update da última localização em hot store,
4. evento para ETA e tracking fanout,
5. amostragem para histórico.

Diagrama

Anti-Spoof

• velocidade impossível,
• salto abrupto,
• drift excessivo,
• sinais de device compromised.

Predição de ETA e Promise Engine (Core 5)

Fórmula

ETA_total = prep_time + pickup_buffer + transit_time + handoff_buffer

Features

1. modelo de preparo por restaurante,
2. modelo de trânsito por modo e via,
3. clima/tráfego,
4. eventos urbanos,
5. histórico de atraso por zona.

API

{
  "order_id": "ord_9011",
  "pickup": { "lat": -23.551, "lng": -46.633 },
  "dropoff": { "lat": -23.560, "lng": -46.655 },
  "restaurant_id": "r_91",
  "courier_id": "cour_887",
  "current_state": "COURIER_AT_RESTAURANT"
}

Resposta:

{
  "eta_minutes": 18,
  "confidence": 0.86,
  "window": {
    "from_minutes": 14,
    "to_minutes": 24
  },
  "updated_at": "2026-02-22T12:42:20Z"
}

Regra de UX

Janela de confiança realista é melhor que ETA pontual super otimista.

Taxas, Precificação e Surge (Core 6)

Componentes de Valor

1. subtotal dos itens,
2. taxa de entrega,
3. taxa de serviço,
4. taxa de pedido pequeno,
5. gorjeta,
6. desconto/cupom,
7. impostos.

Sinais de Surge

• demanda/oferta da zona,
• backlog de dispatch,
• clima severo,
• risco de atraso.

Fórmula ilustrativa

delivery_fee = base
             + multiplier(demand_supply)
             + distance_component
             + weather_component
             - subsidy_component

Guardrails

1. teto de surge,
2. suavização para evitar oscilação brusca,
3. transparência no breakdown,
4. quote TTL curto e claro.

Pagamento e Settlement (Core 7)

Fluxo

1. tokenizar meio de pagamento,
2. autorizar no checkout,
3. capturar no momento definido por política,
4. processar webhooks assíncronos,
5. executar reembolso quando necessário.

Schema

CREATE TABLE payment_attempts (
  payment_attempt_id BIGSERIAL PRIMARY KEY,
  order_id BIGINT NOT NULL,
  provider VARCHAR(32) NOT NULL,
  provider_txn_id VARCHAR(128),
  status VARCHAR(32) NOT NULL,
  amount_cents BIGINT NOT NULL,
  currency CHAR(3) NOT NULL,
  failure_code VARCHAR(64),
  created_at TIMESTAMP NOT NULL,
  updated_at TIMESTAMP NOT NULL,
  UNIQUE (provider, provider_txn_id)
);

Webhook Idempotente

type PaymentWebhook = {
  provider: string;
  eventId: string;
  orderId: string;
  status: "AUTHORIZED" | "CAPTURED" | "FAILED" | "REFUNDED";
  occurredAt: string;
};

async function handlePaymentWebhook(evt: PaymentWebhook) {
  const dedupeKey = `${evt.provider}:${evt.eventId}`;
  if (await dedupeStore.exists(dedupeKey)) return;

  await db.transaction(async (tx) => {
    await tx.paymentEvents.insert(evt);
    await tx.orders.applyPaymentTransition(evt.orderId, evt.status);
    await tx.dedupe.insert({ key: dedupeKey, ttlHours: 72 });
  });
}

Settlement

Distribuir corretamente:

• repasse restaurante,
• ganho entregador,
• fee da plataforma,
• subsídio promocional,
• imposto.

Cancelamento, Reembolso e Compensação (Core 8)

Janelas de Cancelamento

1. antes de aceite do restaurante,
2. após aceite e antes de preparo,
3. preparo iniciado,
4. em rota,
5. após entrega (disputa/reembolso).

Matriz de Compensação

State Flow

Regra

Policy engine versionado e auditável para replay de disputas.

Operação de Restaurante e Capacidade

Sinais de Capacidade

1. fila atual de pedidos,
2. disponibilidade da cozinha,
3. estoque de item,
4. status manual,
5. SLA recente.

Guardrails

• auto-pause,
• inflação dinâmica de prep-time,
• throttle por bucket de tempo,
• indisponibilidade item-level.

Exemplo de Status

{
  "restaurant_id": "r_91",
  "is_open": true,
  "accepting_orders": true,
  "prep_time_minutes": {
    "base": 18,
    "current_dynamic": 27
  },
  "capacity_state": "HIGH_LOAD",
  "updated_at": "2026-02-22T12:39:00Z"
}

Notificações e Comunicação

Canais

1. in-app realtime,
2. push,
3. SMS fallback em eventos críticos,
4. email de recibo.

Eventos

• order placed,
• accepted/rejected,
• courier assigned,
• picked up,
• delivered,
• refund processed.

Pipeline

Regras

• dedupe por (order,event,channel),
• rate limit para evitar spam,
• i18n e timezone corretos.

Caching e Sharding

Camadas de Cache

1. CDN para assets,
2. edge cache para discovery anônimo,
3. Redis para menu hot e carrinho,
4. cache local para configs.

Chaves

restaurants:tile:{geo_hash}:{filters_hash}
menu:{restaurant_id}:v{menu_version}
cart:{customer_id}
eta_preview:{restaurant_id}:{zone_id}
restaurant_status:{restaurant_id}

TTLs

• lista restaurantes: 10-30s,
• menu: 30-120s com invalidação por versão,
• cart: sessão,
• sinal de zona: 1-5s.

Sharding

Arquitetura Event-Driven

Eventos Core

• OrderPlaced
• OrderAccepted
• OrderRejected
• CourierAssigned
• OrderPickedUp
• OrderDelivered
• PaymentAuthorized
• PaymentCaptured
• RefundIssued
• RestaurantCapacityChanged
• CourierLocationUpdated

Diagrama

Outbox Pattern

CREATE TABLE outbox_events (
  event_id UUID PRIMARY KEY,
  aggregate_type VARCHAR(32) NOT NULL,
  aggregate_id VARCHAR(64) NOT NULL,
  event_type VARCHAR(64) NOT NULL,
  payload JSONB NOT NULL,
  created_at TIMESTAMP NOT NULL,
  published_at TIMESTAMP
);

Multi-Região e Disaster Recovery

Topologia

• tráfego roteado para região mais próxima,
• ownership por zonas/cidades,
• replicação assíncrona de dados não-críticos,
• failover com degradação controlada.

Failover Rules

1. manter checkout e order path como prioridade.
2. degradar ranking/discovery antes de checkout.
3. preservar estado de idempotência.
4. pausar transições financeiras arriscadas se reconciliação estiver comprometida.

Segurança, Fraude e Abuse

Controles

1. TLS em todo tráfego.
2. tokenização de pagamento.
3. segregação de privilégio.
4. campos PII cifrados.
5. auditoria de acesso sensível.

Vetores de Fraude

1. abuso de cupom,
2. cartão roubado,
3. spoof de localização,
4. abuso de reembolso,
5. takeover de conta.

Mitigações

Observabilidade e SLOs

SLOs

Golden Signals

Checkout/Payment:

• authorize success,
• decline ratio,
• idempotency replay,
• webhook lag.

Dispatch:

• assignment latency,
• acceptance rate,
• backlog por zona,
• reassign por 1k pedidos.

Tracking:

• ingest QPS,
• staleness ratio,
• drop rate.

Trace IDs

x-request-id
x-order-id
x-dispatch-task-id
x-courier-id
x-payment-attempt-id

Dicas de Entrevista

Fluxo recomendado

1. Delimitar escopo e atores.
2. Estimar picos diurnos.
3. Desenhar 3 caminhos: discovery, transacional, realtime.
4. Deep dive em dispatch.
5. Cobrir idempotência e compensações.
6. Fechar com observabilidade e fraude.

Erros comuns

1. tratar como ecommerce estático,
2. ignorar app de entregador,
3. sem plano de hotspot por zona,
4. sem modelagem de cancelamento,
5. sem webhook idempotente,
6. sem métrica de qualidade de ETA.

Trade-offs

Anti-Patterns

1) Cobrar com valor stale do carrinho

Problema: valor final divergente.

Correção: recomputar no submit.

2) Dispatch síncrono dentro do checkout

Problema: latência explode em baixa oferta.

Correção: criar pedido e disparar dispatch assínc.

3) Acoplar tracking ao state machine de pedido

Problema: falha de telemetria quebra fluxo principal.

Correção: isolar tracking como subsistema.

4) Sem compensação explícita

Problema: estados financeiros/operacionais inconsistentes.

Correção: compensações determinísticas por falha.

5) Ignorar capacidade do restaurante

Problema: aceites além da capacidade real.

Correção: sinais de capacidade no ranking e checkout.

6) Fraude tratada tarde

Problema: unidade econômica degrada rapidamente.

Correção: score de risco desde o início.

7) Sem isolamento de zona quente

Problema: um bairro degrada a plataforma inteira.

Correção: particionamento e autoscaling por zona.

Conclusão

Projetar iFood em escala é orquestrar sistemas independentes com latência baixa e consistência financeira.

Arquiteturas que funcionam compartilham cinco pilares:

1. discovery cacheado e rápido,
2. ordem/pagamento fortemente corretos,
3. dispatch/tracking em event streams de baixa latência,
4. compensações claras para falhas parciais,
5. observabilidade e antifraude de nível operacional.

Esse conjunto é o que diferencia um desenho de entrevista superficial de um desenho que sobreviveria em produção.

Referências

• Google SRE Book
• Apache Kafka Documentation
• Stripe Idempotency
• Designing Data-Intensive Applications
• PostgreSQL Documentation
• Redis Documentation
• Uber Engineering
• Google Maps Platform

Referência Rápida

Componentes

Regras Críticas

1. Nunca confirmar pedido sem persistência durável.
2. Nunca confiar em preço stale no submit.
3. Nunca tratar retry de pagamento como exceção.
4. Nunca acoplar tracking ao core de durabilidade.
5. Sempre modelar cancelamento e compensação.

Estado Base de Pedido

CART -> CHECKOUT_SUBMITTED -> PLACED -> ACCEPTED -> PREPARING -> READY -> PICKED_UP -> DELIVERED
                                    \-> CANCELLED / FAILED / REFUNDED

Prática de Entrevista

1. Projete para chuva forte com escassez de entregador.
2. Reduza tempo de dispatch em zona super densa.
3. Evite duplicidade de cobrança com retries.
4. Modele políticas de cancelamento por estado.
5. Melhore ETA em horario de pico.

Você agora tem um blueprint completo para system design de delivery estilo iFood em escala nacional.