Conectando 60k restaurantes: a saga arquitetural do iFood

Hoje iremos falar sobre a nossa saga para conectar  mais de 60 mil restaurantes ao redor do Brasil. Vamos discutir os problemas que tivemos, nossa arquitetura atual, como chegamos até aqui, e depois fazer um zoom nesta arquitetura atual mostrando tecnologias individuais que nos ajudaram a atingir esse objetivo.

O objetivo desse artigo  é dar um passeio pelo “backstage” do iFood, mais precisamente do time de Connection: o que esse time faz? Quais os desafios? Quão difícil pode realmente ser entregar pedidos para um restaurante?

Mas antes de falar sobre o time e tecnologias, quero contar um pouco de história.

As origens

O iFood começou por volta de 2011 como uma grande empresa de telemarketing. Os clientes ligavam e pediam comida pelos restaurantes favoritos por telefone.

Eventualmente, chegamos no fax. Pois é, fax!

O próximo passo lógico após isso foi um PDV customizado que recebia pedidos fazendo polling em um banco de dados através de um firmware em C.

E tudo isso antes de 2012. O passo era rápido.

O passo que levou isso para cima foi o aplicativo Desktop em 2013. Polling via webservicesSOAP. Bons tempos.

Ainda em 2013 lançamos a primeira versão do aplicativo que fez com que triplicássemos de tamanho, ainda na mesma infraestrutura de SOAP e polling, que rapidamente se mostrou não muito eficiente com a nossa carga atual, nem com a carga futura. Precisávamos de mais performance.

E foi aí que Connection nasceu, um time extraído da necessidade de escala para a entrega de pedidos.

Dias atuais

Eventualmente, após testarmos com diferentes arquiteturas, foi no diagrama acima que chegamos. Vamos falar sobre os diferentes serviços que compõem o nosso time e a solução de entrega de eventos de pedidos.

Gateway Agent

Ingestor de eventos. Basicamente, recebe os pedidos que entram no iFood a partir dos aplicativos mobile e web. Workers ligados por uma fila SQS. Após receber um payload de um pedido e convertê-lo para um formato interno de Connection, o Gateway Agent chama via HTTP o serviço Gateway Core.

Gateway Core

O status de um pedido é um estado complexo. Pedidos confirmados podem ser cancelados, mas pedidos que foram cancelados não podem ser confirmados. Estado complexo é mais fácil se manejado por uma máquina de estados, onde os estados possíveis são definidos através de transições válidas por eventos. E é exatamente como funciona para o ciclo de vida de um pedido.

O Gateway Core implementa uma máquina de estados para o ciclo de vida dos pedidos, validando os diferentes eventos. Estes, após validados, são propagados através de um SNS.

Merchant Connection

Talvez o serviço mais interessante do nosso time. Ele mantém, em memória, em um cluster, todos os heartbeats dos restaurantes da plataforma e, de 5  em 5 segundos, roda um MapReduce no cluster, analisando os heartbeats e transicionando os restaurantes de ONLINE para OFFLINE. É um serviço de conectividade dos restaurantes em tempo real.

O Merchant Connection usa o Apache Ignite como base para a formação do cluster, cacheem memória e funcionalidade de MapReduce.

Order Events

O Order Events é o serviço primário de polling de Connection. Mantém os pedidos dos restaurantes indexados em memória, também em um cluster de Apache Ignite. O cache é particionado, o que significa que ganhamos espaço conforme adicionamos máquinas físicas ao cluster.

O tempo de resposta dele é sempre por volta de 2ms. Para um throughput de 250k RPM no pico em uma plataforma com 60 mil restaurantes, é um número muito bom.

Kitchen API

Uma coleção de micro serviços que respondem requests de fora da infraestrutura do iFood. Nossa API pública. Cada micro serviço corresponde a partes disponíveis para nossos parceiros, desde polling até edição de cardápio.

Connection Polling

Serviço de fallback do Order Events. Você tem sempre que assumir que o que pode dar errado em produção, vai dar errado em produção.

O micro serviço de polling do Kitchen tem um Circuit Breaker que, ao ativar, chaveia requests de polling de eventos para este serviço. Usa o DynamoDB para indexar os novos eventos, a partir do SNS do Core e através de lambdas.

Conclusão

Uma das métricas mais importantes a se otimizar em uma empresa de tecnologia não é performance, tempo de resposta média ou qual a melhor linguagem de programação.

É time to market.

O tempo que leva para você sair do mundo das ideias e para o mundo real, com usuários reais, gerando valor.

Esta é uma métrica muito importante para se otimizar desde o começo. Comece pequeno, comece com as coisas que vão te dar maior produtividade, independente da tecnologia. Os problemas acontecem no ritmo deles, e ter uma atitude mais pragmática reduz o tempo para a geração de valor daquilo que você deseja fazer.

Monolitos nem sempre são ruins, e podem ser que eles te levem a muitos lugares até que perceba que a escala bateu na porta.

No que diz respeito à tecnologia e arquitetura, otimize “escrita vs leitura”. Faça as seguintes perguntas: que tipos de escrita eu terei que fazer? Minhas escritas são maiores que minhas leituras? Separar isso é a chave do sucesso.

Esse artigo é uma breve explicação sobre como está nossa arquitetura, acompanhe o blog pois em breve teremos artigos mais aprofundados em vários desses temas