Vou fazer um projetinho - parte 2
Comecei a pensar em uma arquitetura para o projeto. Como é um projeto de estudos me permite sonhar grande. O projeto vai ser um grande sucesso no primeiro dia.
Então, os primeiros ensaios são com esse pensamento em mente.
Spoiler: Nos episódios eu coloco o pé no chão :)
O Brasil tem mais de 5500 cidades. Vamos arredondar para 6000. Em média há dois supermercados por cidade - segundo o instituto “Minha cabeça Ltda”. O instituto diz também que num dia de pico existem em média 20 pessoas em cada supermercado.
Supondo que todas as pessoas enviaram uma atualização de preço ao mesmo tempo, o nosso backend vai receber 240k requests no mesmo segundo.
Primeiro precisamos dar conta de receber esses requests, o que vai ser feito com eles podem ficar para um segundo momento. Sendo assim, o desenho a seguir é plausível.
O price-ingester, recebe a requisição, responde com um 202 e envia para o kafka (ou kenesis, pubsub, redpanda …). Daí pra frente decidimos como tratar o dado.
Só pra não ficarmos tão vulneráveis, seria interessante ter uma camada de autenticação no início. O que você acha?
Quem faz o papel da autenticação é o API Gateway. Mas aí você pensa: “O API Gateway já não pode enviar direto para o kafka?”
Poder, até pode. Particularmente não gosto da ideia. Vamos pensar em alguns cenários hipotéticos:
Para cada região do Brasil eu quero um tópico distinto no kafka. O API Gateway teria que fazer esse split.
Ao invés de enviar uma mensagem de cada vez para o kakfa eu quero enviar batchs. Minha regra de negócio tolera eventuais perdas de buffer. Isso seria implementado no API Gateway.
O API Gateway deve fazer coisas de API Gateway e não deveria começar a absorver regras de negócio.
Em breve, parte 3.