O documento descreve a evolução da arquitetura de dados do iFood, começando de uma arquitetura monolítica para microserviços. O PostgreSQL é amplamente utilizado para armazenar dados transacionais e não transacionais para vários microserviços. Uma nova plataforma de busca de restaurantes foi desenvolvida para integrar dados de múltiplos serviços no PostgreSQL de forma consistente e escalável. Mensagens entre serviços são trocadas usando SNS/SQS para disparar eventos assíncronos.

1. PostgreSQL na plataforma
de dados do iFood
Veja como o iFood trabalha com dados, saindo do app,
passando pelos micro-serviços, residindo em várias
instâncias do PostgreSQL, e sendo populados por completo
em nosso Datalake.
Matheus de Oliveira
<matioli.matheus@gmail.com>
PGConf.Brasil (2018-08-03)

2. O menu dessa palestra
1. Evolução tecnológica do iFood
2. Do mono-lito aos micro-serviços
3. O PostgreSQL no iFood
4. Plataforma de busca
5. Troca de mensagens entre serviços
6. Juntando tudo!

4. Evolução tecnológica do iFood

5. Em números
4
países
530+
cidades
8.200.000+
pedidos por mês
1.500+
pedidos entregues por
minuto
100%+
crescimento ao
ano

6. E ainda temos muita margem para crescer
Ref: http://exame.abril.com.br/marketing/brasileiros-app-
comida-delivery/

7. Mas não é tão simples quanto parece...

8. Restaurante Consumidor Entregador

9. Padrão de consumo

10. Time Tecnologia meados 2015

11. HOJE

12. Novo prédio em Campinas
(time de tecnologia) - 2017
Venha trabalhar conosco: ifood.delivery/br/vagas

13. Micro-serviços no iFood

14. Arquitetura monolítica
Internal Network
End Users
Database
Webservice
Backoffice
Restaurant
And Integrations
Website
Backoffice
Operators
Analytics

15. Arquitetura de micro-serviços
Internal NetworkEnd Users
Webservice
Backoffice
Restaurant
And Integrations
Backoffice
Operators
APIGateway
Website
Integration
Order
Discovery
Restaurant
Logistic
Payment
...
+50 microserviços
Legacy
Microservice

16. Nossa arquitetura padrão

17. Vamos de nir um padrão...

18. O PostgreSQL no iFood
Hoje temos mais de 50 bancos de dados
A maioria altamente transacionais
Alguns com muita escrita, outros com muitas leituras
Alguns com alta taxa de UPDATE, outros com
arquitetura de banco imutável (append-only)
Em geral os esquemas são pequenos, menos de 50
tabelas (um deles tem apenas uma tabela, por exemplo)
Mas os tamanhos variam de alguns megabytes até mais
de 1TB

19. Plataforma de busca de restaurantes

20. O problema: dados de vários serviços integrados na mesma tela/visualização

21. Plataforma de busca de restaurantes
Solução atual!

22. Plataforma de busca de restaurantes
Problemas com a solução atual:
Sincronização dos dados complexa, difícil garantir
consistência
Tempo de sincronia alto quando muita alteração é feita e
eventual perda de sincronia
Várias tecnologias na mesma plataforma
Di culdade de debug (origem dos dados espalhados,
tornando difícil "juntar" tudo e validar)
Di culdade em gerenciar caches entre as várias camadas
Dependência de outros serviços (que poderiam não ser
críticos, como o "Location Service"), di culta manutenção
e escalabilidade

23. Nova plataforma de busca de restaurantes
origem dos dados
Instâncias dos serviços de origem, todas usando PostgreSQL
como base de dados

24. Nova plataforma de busca de restaurantes
extração dos dados
Replicação das bases PostgreSQL de cada serviço para uma
base central (cada origem num schema), usando replicação
lógica (nativa)

25. Nova plataforma de busca de restaurantes
processamento dos dados
Cada tabela replicada possui uma trigger, que processa os
dados e alimenta tabelas com esquema otimizados pra
busca (de-normalizados)

26. Nova plataforma de busca de restaurantes
isolamento das tabelas otimizadas
Por sua vez, apenas as tabelas otimizadas são replicadas (via
replicação lógica) para a base dedicada para busca

27. Nova plataforma de busca de restaurantes
balanceamento de carga, elasticidade na busca
Essa base replica, usando replicação física nativa, para N
instâncias num group de Auto Scaling.
N irá variar dependendo do uso no horário

28. Nova plataforma de busca de restaurantes
camada de serviço
Por m, o serviço conecta no ELB (Elastic Load Balancer) das
instâncias em Auto Scaling para responder às buscas dos
usuários

29. Nova plataforma de busca de restaurantes
integração com data intelligence
Integração com serviço de data intelligence para prover
ranking no contexto do usuário

31. Troca de mensagens e dados entre
serviços

32. AWS SNS - Simple Noti cation Service
Tópicos que recebem mensagens e repassam para
múltiplos receptores com diversos protocolos (como
la SQS, e-mail, SMS, chamada HTTP, etc.)
No iFood, sempre que um serviço quer enviar eventos
para outros consumirem, este serviço faz uma publicação
desse evento num tópico SNS.
AWS SQS - Simple Queue Service
Fila altamente escalável.
No iFood, sempre que um serviço quer receber eventos
de outro, criamos uma la SQS para este que assina o
tópico SNS do serviço de origem.

33. SNS/SQS - Exemplo

34. Juntando tudo!

35. Datalake (visão geral)

36. Perguntas?

37. Obrigado!
Matheus de Oliveira
irc.freenode.net -
/join #postgresql,#postgresql-br: @MatheusOl
Twitter:
LinkedIn:
SlideShare:
matioli.matheus@gmail.com
@matioli_matheus
br.linkedin.com/in/matheusdeoliveira/
slideshare.net/matheus_de_oliveira