Executando verificação de segurança...
2

Muito interessante a pergunta! Vamos por parte.

Metodologia 12 fatores (The Twelve-Factor App)

Algo paupável que você pode (deve) ter em mente ao desenvolver uma aplicação escalável do jeito certo é seguir a metodologia dos doze-fatores (https://12factor.net/pt_br/).

De modo bem simplista, essa metodologia, se seguida corretamente, permite que sua aplicação seja escalável, além de garantir que boas práticas de desenvolvimento foram seguidas.

Ainda que inicialmente você não possa/consiga seguir todas elas, você terá um norte para saber o que deve ser feito num futuro próximo.

Práticas Recomendadas

Outras práticas do dia-a-dia que recomendo são:

Porque usar cada uma dessas práticas?

  1. O Load Balancer vai distribuir a carga entre as instâncias da sua aplicação. Desse modo, você vai conseguir por exemplo rodar 3 instâncias da aplicação em 3 máquinas diferentes, evitando que uma única instância fique sobrecarregada.
    Isso é o que chamamos de escalabidade horizontal. Se surgir a necessidade de aumentar o número de instâncias, basta subir novas instâncias e configurar o load balancer para redistribuir a carga também para elas.

  2. Quando você conteineriza uma aplicação, permite que ela rode em múltiplos ambientes, com por exemplo diferentes arquiteturas. Isso permite por exemplo você usar máquinas de mais baixo custo, como por exemplo as que usam a plataforma ARM na nuvem da Oracle.
    Além disso, um container já tem todas as dependências necessárias para a execução da aplicação, o que torna a implantação da aplicação muito mais fácil.

  3. O uso do Kubernetes como orquestrador de containers vai trazer diversas vantagens para você, como por exemplo:

    • Utilização de healthchecks para avaliar a saúde dos seus containers
    • Possibilidade de atualização com zero downtime, ou seja, o cliente nem vai perceber que você está atualizando a aplicação
    • Facilidade para escalar horizontalmente sua aplicação
    • Integração com plataformas de nuvem como AWS
    • E muitas outras
  4. Uma CDN (Content delivery network) vai permitir que recursos como imagens, css e outros tipos de recurso que podem ser cacheados sejam distribuídos pela rede, sem que a sua aplicação tenha que consumir recursos para fazer esse serviço

Eu não sei nada disso, e não sei por onde começar

Minha sugestão é começar com passos pequenos. O primeiro deles é montar um ambiente de testes usando Docker Compose. Com o Docker Compose você consegue já aprender e testar diversas questões relacionadas ao item 1 e 2. Num caso simples, você teria 3 serviços: O Load Balancer (NGINX ou qualquer outro semelhante), as instâncias da sua aplicação do frontend (eventualmente poderia o próprio load balancer executá-la), as instâncias da aplicação do backend e o banco de dados. Imagens para Load Balancers e bancos tem aos montes no https://hub.docker.com/.

A sintaxe do Docker compose é bem simples, e vocÊ pode aprender aqui por exemplo: https://docs.docker.com/compose/gettingstarted/

Aí vai ficar faltando você criar o(s) Dockerfile(s) da sua aplicação. Como você está pensando em usar NextJS, um site bem didático é esse daqui:

https://www.koyeb.com/tutorials/how-to-dockerize-and-deploy-a-next-js-application-on-koyeb

Uma vez definido esse ambiente local, você já poderá testar a utilização de variáveis de ambiente. Isso é interessante por que vai permitir que você mude o comportamento da sua aplicação, dependendo do ambiente em que ela estiver.

Dominado esse passo, você vai poder partir para o Kubernetes. Para aprender, é só seguir a série https://youtu.be/gEyOJAVkwZ4

Realmente preciso de tudo isso?

Aí depende de cada caso, mas é muito provável que com uma única instância você consiga atender toda a demanda por três motivos:

  • Normalmente os clientes tendem a sobrestimar a carga que receberão
  • Esse número de cadastros (4 milhões) vai ser diluído ao longo dos dias. O que eu quero dizer é que num determinado momento, é muito provável que você não tenha esse número de usuários acessando simultaneamente
  • Pela descrição inicial da aplicação, não parece ser uma aplicação que vai demandar grande poder de processamento

Espero que possa ter coloborado ao menos um pouco com suas dúvidas! Mas se quiser, fique à vontade para perguntar mais coisas!

Carregando publicação patrocinada...
1

Nossa eu não sei nem como agradecer KKKKKKKKKKK eu estou realmente muito perdido nesse momento inicial nunca nem fiz um deploy de uma aplicação pra algum cliente na vida, geralmente quem faz essa parte é meu superior, muito obrigado mesmo vou dar uma olhada nos conteudos que você passou

No momento a unica coisa q eu to pensando é no tamanho do servidor que eu vou ter que contratar, o cliente falou que oque eu falar que precisa pra hostear ele vai pagar só que eu n queria passar um valor e acabar sobrando muito, sei que é quase impossivel determinar isso com certeza mas por exemplo uma maquina com 4 nucleos ja é muita coisa pra uma aplicação como essa com essa quantidade de usuarios?

1

@Mikaellpc, desculpe a demora. Eu acho que é importante analisar a seguinte situação. Se você conseguir automatizar o esquema de implantação da sua aplicação, vai ser fácil, caso esteja superestimada a capacidade do servidor, de fazer a implantação numa máquina mais adequada.

Se você conseguir monitorar o consumo de recursos da máquina ao longo por exemplo de uma semana (isso é muito fácil nas nuvens), vai conseguir identificar picos de acesso e de consumo de recursos. Com isso, vai saber a capacidade máxima utilizada e vai poder dimensionar melhor a máquina.

Segundo você "o cliente falou que oque eu falar que precisa pra hostear ele vai pagar". Então aproveita, começa com uma capacidade maior (claro, não precisa pegar a máquina mais forte disponível por exemplo, rsrs), avalia durante uma semana, e aí redimensiona.

Pode ter certeza que desse modo, você vai mostrar seu comprometimento profissional, de procurar sempre melhorar, e além disso, é MUITO MELHOR ele pagar um pouco a mais do que deveria, mas GARANTIR que todos os clientes dele serão atendidos adequadamente, do que o contrário, ou seja, "economizar alguns dólares", e no momento de pico travar todo o sistema.

É seu primeiro projeto grande, não tente ser perfeito desde o início. Comece com excesso de zelo, e vai afiando o machado conforme for ganhando mais entendimento da aplicação.