Decisão de Arquitetura para Banco de Dados da API RMS
Data: 2024-02-27
Status: Proposta
A API é responsável por registrar pedidos dos clientes, processar transações de pagamento e disponibilizar atualizações de status dos pedidos. O contexto inclui a necessidade de equilibrar a robustez do sistema, a eficiência operacional e a capacidade de escalabilidade para atender às demandas em um ambiente dinâmico e movimentado, caracterizado por um grande volume de transações simultâneas. Diante desses desafios e requisitos específicos, a escolha do banco de dados tornou-se crucial no processo de arquitetura da aplicação. Além disso, a decisão de arquitetura para o banco de dados deve levar em conta aspectos como a modelagem de dados relacional, suporte transacional, desempenho e a capacidade de lidar com estruturas de dados complexas, bem como considerações práticas, como custo e suporte da comunidade.
Modelo: Relacional
SGBD: PostgreSQL v16.1
Infraestrutura: Amazon RDS
Entendemos que no Tech Challenge os dados da aplicação são essencialmente relacionais: Clientes se relacionam com Pedidos, que por sua vez se relacionam com Produtos e com Categorias. Após análise das principais opções disponíveis, entendemos que o modelo relacional é o que mais se adequa para o nosso problema de negócio, contexto atual e requisitos.
DER - Diagrama Entidade-Relacionamento
Ao optar pelo modelo relacional, optamos por utilizar o SGBD PostgreSQL, por entendermos que ele proporciona uma modelagem de dados relacional eficiente, permitindo a representação das entidades de Clientes, Pedidos e itens do menu como Categorias e Produtos. Sua robustez e suporte a transações ACID é crucial para garantir a consistência e confiabilidade das operações envolvidas no registro de pedidos e também no registro do processamento de pagamentos. O PostgreSQL também é famoso e bem aceito na comunidade por oferecer desempenho sólido e recursos avançados de otimização, atendendo a exigência de tempo de resposta rápida necessária em ambiente dinâmico e movimentado. O PostgreSQL permite gerenciar eficazmente um grande volume de transações simultâneas.
💡A escolha do PostgreSQL, por ser uma solução de código aberto, alinha-se com considerações orçamentárias, proporcionando uma opção econômica adequada ao nosso cenário.
Além disso, outros motivos que embasaram a nossa escolha foram:
- O poder e flexibilidade da linguagem de consulta SQL facilita a geração de relatórios e a junção, agregação, filtragem e ordenação dos dados;
- O modelo relacional e a linguagem SQL são populares, mesmo entre os profissionais de nível mais iniciante que possam vir a fazer parte da equipe;
- A normalização, o schema, a integridade referencial e a consistência ajudam a impor disciplina, contribuindo para uma melhor qualidade de dados;
- Suporte a transações ACID, garantindo atomicidade, consistência, isolamento e durabilidade dos dados;
- Pode ser utilizado também opcionalmente em conjunto com um banco de dados do tipo Key-Value/Chave-Valor como cache, como o Redis ou memcached no AWS ElastiCache por exemplo. Apesar de acreditarmos que, por hora, ainda não se faz necessário.
- Também podem trabalhar em clusters (com algumas limitações importantes quando comparado ao NoSQL) através da criação de Réplicas muti-AZ somente leitura no modelo master/slave, com replicação assíncrona, oferecendo tolerância a falhas. Apesar de acreditarmos que, por hora, ainda não há essa necessidade.
Por que não optamos pelo modelo de Documentos?
Em nosso cenário Clientes se relacionam com Pedidos, que por sua vez se relacionam com Produtos e com Categorias. Precisamos frequentemente cruzar esses dados. Os bancos de dados de Documentos como o MongoDB por exemplo, apesar de terem se tornado muito populares nos últimos anos não são indicados para cenários onde os dados tem muitos relacionamentos. Apesar de permitir que um documento referencie o outro, há degradação de performance ao executar queries quando há muitas referências e agregações, quando os pipelines possuem muitos stages. Isso poderá dificultar a geração de relatórios de vendas mais complexos, por exemplo.
Por que não optamos pelo modelo Colunar?
Nosso grupo viu no modelo Colunar uma alternativa poderosa, performática e escalável porém, após análise chegamos à conclusão de que os dados da aplicação não se beneficiariam muito de um esquema flexível, oferecido pelos bancos de dados Colunares como o Cassandra ou ScyllaDB, já que os dados de Clientes, Pedidos, Produtos e Categorias terão sempre os mesmos atributos e colunas. Além disso, Clientes, Pedidos, Produtos e Categorias se relacionam e a ausência de relacionamentos, integridade referencial, ausência de normatização e a ausência do comando JOIN poderia introduzir consequentemente altas complexidades dentro da aplicação e também dificultar a geração de relatórios complexos e variados de acordo com a demanda de cada lanchonete. Sendo assim, acabamos optando pelo modelo relacional que também oferece tolerância a falhas através de Replicas de leitura muti-AZ que podem assumir caso a master encontre problemas.
Porém, entendemos que para o futuro o Amazon Redshift pode ser uma solução interessante para a implantação de uma solução de Data Warehouse, apesar deste ainda não ser um requisito do Tech Challenge.
Por que não optamos pelo modelo Chave-Valor?
Por hora optamos por não utilizar ainda um banco de dados Chave-Valor. O modelo Chave-Valor é limitado e não atende bem as necessidades de junção e agregação para ser adotado como banco de dados principal para o Tech Challenge. Porém, entendemos que o modelo chave-valor poderia ser utilizado no futuro, como cache em memória para melhorar a latência e tempo de resposta da nossa aplicação.
Nossa aplicação é relativamente pequena e ainda possui poucos usuários, porém, o AWS ElastiCache com Redis será a nossa primeira opção no futuro quando a aplicação alcançar uma quantidade significativa de usuários simultâneos. Ao combinar o Amazon RDS (PostgresSQL) com o AWS ElastiCache (Redis) podemos aliviar a carga sob a instância do PostgresSQL e melhorar a performance e latência da aplicação. Nessa ocasião, optaremos por utilizar a política de despejo de chaves (Eviction Policy) LRU - Least Recently Used allkeys-lru no Redis.
Por que não optamos pelo modelo de Grafos?
Em nosso cenário Clientes se relacionam com Pedidos, que por sua vez se relacionam com Produtos e com Categorias. Apesar de possuirmos alguns relacionamentos, entendemos que a quantidade e complexidade dos relacionamentos no nosso projeto ainda é relativamente pequena para justificar a adoção de um banco de dados de Grafo mais robusto nesse sentido. Além disso, os nossos relacionamentos entre Clientes, Pedidos, Produtos e Categorias não são variáveis, serão sempre os mesmos.
Por que não optamos pelo modelo de Séries Temporais?
Nossa aplicação não armazena dados temporais, como histórico de preços por exemplo. Sendo assim, não vemos aplicabilidade do modelo de séries temporais em nosso projeto.
Por que não optamos pelo modelo de Engine de Buscas?
Nossa aplicação não realiza buscas textuais por produtos ou categorias, esse não é um requisito para o Tech Challenge. Sendo assim, não vemos aplicabilidade do modelo de engine de buscas e índice invertido, como o Elasticsearch ou Apache Solar por exemplo. Porém, entendemos que poderíamos eventualmente no futuro utilizar o ElasticSearch através da stack EFK para armazenamento e análise e agregação de logs, apesar deste não ser um requisito para o Tech Challenge.
Ao escolher o PostgreSQL como banco de dados para a API, esperamos contribuir significativamente para a eficiência operacional, garantindo tempos de resposta rápidos, manuseio de dados complexos e escalabilidade confiável, promovendo uma experiência positiva para os usuários finais.