Entrega de comida e entrega local rápida (iFood/DoorDash/Gopuff)

01 · CONTEXTO E REQUISITOS

Duas perguntas em uma: o que posso entregar aqui e quem leva

Entrega de comida e entrega local rápida parecem um problema só, mas escondem duas perguntas. A primeira é de catálogo: quais itens dá para entregar naquela localização agora. A segunda é de logística: depois do pedido, qual entregador leva e quando ele deve sair. Este caso usa uma fonte de preparação para entrevistas, sobre uma empresa de conveniência, para a primeira pergunta, e uma publicação do iFood para a segunda.

A fonte de conveniência descreve entrega rápida a partir de 500+ microcentros de distribuição. O requisito central é consultar a disponibilidade dos itens entregáveis em uma hora, por localização, somando o estoque dos centros próximos. A consulta precisa ser rápida, abaixo de cem milissegundos, e o pedido precisa ser fortemente consistente: dois clientes não podem comprar o mesmo produto físico. A própria fonte assume pedidos na ordem de dezenas de milhões por dia.

A fonte deixa o roteamento de entregadores fora do escopo. É por isso que a segunda metade do caso olha para a publicação do iFood, que descreve como pedido, entregador e tempo de cozinha entram na decisão de despacho.

02 · DISPONIBILIDADE

Quais centros alcançam o cliente a tempo

1. O app envia a localização do cliente ao serviço de disponibilidade, junto com os itens que ele procura.

2. O serviço de disponibilidade pergunta ao serviço de centros próximos quais centros alcançam o cliente; este filtra candidatos e consulta o serviço externo de tempo de viagem.

3. Com os centros em mãos, o serviço olha primeiro o cache de disponibilidade.

4. Sem resposta no cache, a consulta cai nas réplicas de estoque, que somam o estoque dos centros; o resultado volta ao cache.

5. O banco líder fica reservado às escritas de pedido; as leituras de disponibilidade vão às réplicas.

Medir só a distância em linha reta engana: um centro pode estar perto em distância e longe em tempo de viagem, por causa de um rio ou de uma fronteira, e a conta simples também ignora trânsito e condições das vias. Por outro lado, perguntar o tempo de viagem de todos os centros ao serviço externo gera consultas demais, já que a maioria nunca chegaria a tempo.

03 · ESCALA DE LEITURA

Muitas consultas, poucas compras

A fonte parte do volume de pedidos por dia para estimar cerca de 20 mil consultas de disponibilidade por segundo. Para essa carga, ela aponta cache agressivo com TTL curto. A contrapartida é que o serviço de pedidos precisa expirar as entradas afetadas quando grava no estoque.

A segunda saída é combinar particionamento e réplicas de leitura. A fonte agrupa os centros por região, usando os primeiros dígitos do CEP, de modo que as consultas caem em poucas partições. As leituras de disponibilidade podem ir às réplicas porque toleram pequena inconsistência; as transações de pedido vão ao líder.

04 · PEDIDO E CONSISTÊNCIA

Não vender o mesmo item duas vezes

1. O app envia ao serviço de pedidos o pedido com vários itens.

2. O serviço abre uma única transação no banco líder: confere o estoque, registra o pedido e atualiza o estoque, tudo junto.

3. Se algum item deixou de estar disponível, o pedido inteiro falha.

4. Depois de gravar no estoque, o serviço de pedidos expira as entradas do cache que ficaram desatualizadas.

5. As consultas de disponibilidade continuam sendo atendidas pelas réplicas de leitura.

Para não vender o mesmo estoque a dois usuários é preciso alguma forma de trava. Com dois bancos, um para pedidos e outro para estoque, a fonte lembra os modos de falha: a queda do serviço entre criar o pedido e baixar o estoque, e dois pedidos com estoque sobreposto. Como alternativa, ela descreve uma transação única num só banco, que registra o pedido e atualiza o estoque.

05 · DESPACHO DE ENTREGADORES

O mais próximo não basta

1. O cliente fecha o pedido e o serviço de pedidos repassa as informações ao restaurante.

2. O restaurante tem por volta de 8 minutos para confirmar; sem confirmação, o pedido é cancelado automaticamente.

3. Os modelos de previsão informam o tempo de cozinha, que ajuda a decidir quando mandar o entregador ao restaurante.

4. O app do entregador envia um fluxo constante de dados; o despacho precisa saber a frota, as posições e quem pode pegar um pedido.

5. O otimizador testa hipóteses de rotas entre pedidos e entregadores, buscando minimizar atrasos; agrupa pedidos só se nenhum deles atrasar.

6. O monitoramento acompanha pedidos e atrasos ao vivo; um pedido atrasado gera uma ocorrência automática.

A decisão é tomada minuto a minuto, numa escala muito maior que a de um entregador isolado. O objetivo é achar o melhor entregador para cada pedido, de modo que ele chegue a tempo ao restaurante e depois ao cliente. Os pedidos nascem o tempo todo, espalhados pela cidade.

06 · SÍNTESE

Garantias diferentes para caminhos diferentes

Disponibilidade, pedido e despacho pedem garantias diferentes, e o desenho melhora quando cada caminho recebe a sua. A leitura de disponibilidade pode usar cache e réplicas. O pedido exige consistência forte e, nas fontes, vai a uma transação única. O despacho trabalha com informação que muda o tempo todo e com regras de prazo prometido; no desenho didático, pedidos e posições chegam a ele por um fluxo de eventos.