Loading repository data…
Loading repository data…
g12-4soat / repository
Repositório dedicado ao projeto TechChallenge da FIAP - Turma 4SOAT - Fase 1 & Fase 2
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
Repositório dedicado ao projeto TechChallenge da FIAP - Turma 4SOAT
Há uma lanchonete de bairro que está expandindo devido seu grande sucesso. Porém, com a expansão e sem um sistema de controle de pedidos, o atendimento aos clientes pode ser caótico e confuso. Por exemplo, imagine que um cliente faça um pedido complexo, como um hambúrguer personalizado com ingredientes específicos, acompanhado de batatas fritas e uma bebida. O atendente pode anotar o pedido em um papel e entregá-lo à cozinha, mas não há garantia de que o pedido será preparado corretamente.
Sem um sistema de controle de pedidos, pode haver confusão entre os atendentes e a cozinha, resultando em atrasos na preparação e entrega dos pedidos. Os pedidos podem ser perdidos, mal interpretados ou esquecidos, levando à insatisfação dos clientes e a perda de negócios.
Em resumo, um sistema de controle de pedidos é essencial para garantir que a lanchonete possa atender os clientes de maneira eficiente, gerenciando seus pedidos e estoques de forma adequada. Sem ele, expandir a lanchonete pode acabar não dando certo, resultando em clientes insatisfeitos e impactando os negócios de forma negativa.
Para solucionar o problema, a lanchonete irá investir em um sistema de autoatendimento de fast food, que é composto por uma série de dispositivos e interfaces que permitem aos clientes selecionar e fazer pedidos sem precisar interagir com um atendente. E, para que isso aconteça, criamos um sistema de controle de pedidos robusto e eficiente para a lanchonete em expansão, visando otimizar o atendimento ao cliente e garantir uma gestão adequada dos pedidos e estoques. A arquitetura do sistema será centrada em um aplicativo de autoatendimento intuitivo, permitindo que os clientes personalizem seus pedidos de maneira fácil e rápida, escolhendo lanches, acompanhamentos, bebidas e sobremesas.
Nesse primeiro momento o sistema integrará apenas com a opção de pagamento via QR Code do Mercado Pago, porém no futuro poderão ser implementadas novas opções de pagamento com o objetivo de proporcionar uma maior flexibilidade aos clientes.
A escalabilidade será um ponto-chave na arquitetura, permitindo que o sistema se adapte facilmente ao aumento e diminuição da demanda. Utilizamos as melhores tecnologias e práticas disponíveis no mercado para assegurar a eficiência operacional mesmo em momentos de alta demanda. A arquitetura sistêmica e de infraestrutura facilitará futuras atualizações e integrações no sistema.
A aplicação possuí atualmente uma estrutura monolítica que está modularizada, visando como objetivo implementar uma estrutura de micro serviços no decorrer do projeto. Utilizamos o Github para gerenciar todo o código fonte, implementando automações CI/CD através do Github Actions. Além disso, fazemos uso do DockerHub como Container Registry para gerenciar as imagens de containers do projeto. Todos os nossos serviços internos são gerenciados pelo Cluster Kubernetes, que realiza a orquestração de todos os recursos da aplicação.
API: Tem como responsabilidade o recebimento e envio de requisições REST para a aplicação Tech Lanches.
Fila de Pedidos: Serviço do tipo "background service" que executa e gerencia a fila de pedidos.
Application Core: Responsável por implementar os principais requisitos da aplicação.
SQL Server: Banco de dados relacional cujo a responsabilidade é cuidar do armazenamento de dados.
ACL Pagamento: Intermediário entre a comunicação da API com o serviço externo do Mercado Pago, visando a proteção da API para que não seja impactado diretamente na aplicação caso algo no serviço seja modificado.
Mercado Pago: Serviço externo utilizado para efetuação de pagamento dos pedidos. Para mais informações sobre a implementação clique no nome do serviço.
NGROK: Utilizamos como intermediário para realizar a comunicação do Mercado Pago com a API Tech Lanches, atráves de uma URL estática que é enviada ao webhook do Mercado Pago, que após a efetivação do pagamento é enviado uma requisição para o NGrok com o status do pagamento que faz o redirecionamento para o endpoint responsável da API Tech Lanches. Para mais informações clique no nome da ferramenta.
RABBITMQ: Utilizado para auxiliar a fila de pedido no controle e gerenciamento. Para mais informações clique no nome da ferramenta.
Na arquitetura Kubernetes (K8S), utilizamos o próprio Kubernetes em conjunto com o Docker como provedor de infraestrutura, buscando explorar plenamente os recursos nativos oferecidos pelo Kubernetes. Dentro do cluster Kubernetes, estabelecemos o namespace "techlanches", designado para armazenar todos os recursos relacionados diretamente à aplicação. Adicionalmente, temos o namespace "kube-system", destinado a objetos criados pelo sistema Kubernetes. No contexto do namespace "techlanches", trabalhamos na segmentação dos componentes com base nas responsabilidades, buscando facilitar a compreensão visual da estrutura arquitetônica. Essa abordagem visa proporcionar uma organização clara e compreensível dos elementos envolvidos na aplicação.
TechLanches.API: Implementamos um Deployment com replicas 1/1 para garantir a disponibilidade da aplicação durante períodos de baixa demanda. Além disso, incorporamos um serviço Load Balancer responsável pelo balanceamento de carga entre os Pods e expor a API para a internet na porta 5050 do Container. Para monitoramento, integramos Probes do tipo Liveness, que verifica a execução adequada da aplicação TechLanches e a resposta correta a todas as solicitações, assim como Readiness, que assegura que a aplicação está pronta para receber requisições. Adicionalmente, contamos com ConfigMap que nos auxilia no armazenamento de configurações, Secrets para armazenamento de dados e senhas privadas e também incluímos um HPA 1/5 para escalabilidade automática, aumentando a quantidade de instâncias em caso de utilização de memória superior a 50%. Esse processo de escalabilidade é revertido de forma proporcional à redução no uso de memória do container, garantindo alta disponibilidade e resiliência nos serviços.
TechLanches.WORKER: Adotamos uma estrutura semelhante à empregada na API, exceto a ausência da implementação do serviço Load Balancer. Além disso, incorporamos um HPA 2/5 para escalabilidade automática, considerando-o como o motor da aplicação para otimizar eficiência em todo o processo do pedido.
TechLanches.SQL: Optamos por implementar um StatefulSet neste contexto devido à sua adequação para lidar com bancos de dados. Isso se deve à sua característica de implementar cada réplica após a anterior estar 100% funcional, iniciando e encerrando os Pods em sequência, ao contrário do Deployment, que o faz em paralelo. O StatefulSet inclui replicas 1/1 e um serviço Load Balancer, semelhante ao contexto da API. No entanto, difere ao