Loading repository data…
Loading repository data…
epiresdasilva / repository
Backend serverless que simula o sistema de votação do BBB
Esse é um projeto de exemplo de arquitetura serverless usando como inspiração a votação para eliminação do paredão do BBB. Nessas votações, o sistema da Globo recebe uma alta carga de execuções e precisa de uma arquitetura que consiga processar tudo isso.
Explicação sobre cada recurso utilizado
Esse desenho de arquitetura mostrado anteriormente é a versão final, mas precisei iterar sobre ele para chegar nessas conclusões. Por isso, quero registrar também as escolhas que não atenderam as necessidades. Para começar, é importante dizer que serverless te entrega escala sem preocupação, mas isso não significa que você terá a escala necessária para resolver o seu problema. Isso porque cada serviço tem suas característica e apesar de em termos de infraestrutura você não ficar na mão, você pode ainda ter problema de vazão.
Na primeira tentativa, utilizei o SQS conectado ao API Gateway para receber os votos de forma assíncrona direto do endpoint. Em termos de disponibilidade não tive nenhum problema, mas o consumo dessas mensagens não atendia a velocidade de contabilização de votos que precisava. Por esse motivo, o uso de um Broker como o EventBridge fez mais sentido.
Também na primeira versão da arquitetura, ao invés do uso de SQS como Destination da Lambda de registro de votos, eu havia utilizado a Lambda conectada no DynamoDB Stream para ouvir os eventos de cadastro. Em termos funcionais funcionou muito bem, mas assim como o Kinesis, o DynamoDB Stream trabalha com o conceito de shard. Sendo assim, só é possível paralelizar a mesma quantidade de shards configuradas no DynamoDB.
Mesmo tendo a opção de paralelizar e aumentar a capacidade, ainda ficou aquém da velocidade necessária para o problema.
Esse projeto utiliza Serverless Framework para gerar a infraestrutura como código. Por esse motivo, fica fácil reproduzir essa aplicação em sua própria conta da AWS.
Basta executar o comando abaixo na raiz do projeto:
sls deploy
Antes de realizar uma chamada para o endpoint, você precisa criar uma tabela no seu banco de dados RDS:
create table vote_bag_count (id serial primary key, name text, vote_count integer, saved_at timestamp);
O desenvolvimento todo foi realizado dentro de uma semana, trabalhando somente em dias úteis em torno de 2 horas por dia. Um total de 10 horas de desenvolvimento.
Os valores abaixo são do intervalo todo de desenvolvimento, portanto esses custos incluem todos os testes realizados inúmeras vezes e não somente o teste final que resultou na estatística citada anteriormente.