- Movile .
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