AZ Docs — Infraestrutura

Síntese

Conclusão

No volume de hoje, os quatro serviços cabem numa única máquina de 2 núcleos e 8 GB — inclusive com a moderação automática ligada. A soma medida fica entre 2,7 e 3,3 GB, o disco em torno de 12 GB de 80, e o pico de tráfego não passa de 1 requisição por segundo com 500 usuários diários.

Não há, portanto, urgência de capacidade que justifique um segundo servidor. Neste volume, a hipótese de que os quatro serviços não caberiam na máquina atual não se sustenta.

Isso desloca o critério da decisão. Separar deixa de ser questão de capacidade e passa a ser de isolamento e margem: qualquer publicação do servidor principal interrompe os quatro ao mesmo tempo, e um vídeo em moderação ocupa metade da máquina por alguns segundos — tempo suficiente para afetar um checkout em andamento.

1,04 req/s no pico Com 500 usuários/dia. É o tráfego de um site pequeno.

0,42% do dia em moderação Pior cenário: 500 usuários, 30% publicando.

12 GB de disco, de 80 Fotos e vídeos vão para a Cloudflare, não para o servidor.

84% da memória é da mídia 2,5 GB dos 2,9 GB somados. Custo fixo, mesmo sem publicações.

Recomendação

Manter os quatro serviços na máquina atual e, no curto prazo, limitar a análise local a um núcleo (OMP_NUM_THREADS=1) e elevar o teto de memória da mídia para 3 GB. Passar a moderação inteiramente para a Cloudflare Workers AI elimina cerca de 2,3 GB de memória residente e o pico de processamento, mas exige alteração de código — hoje a camada local é executada em todos os casos. A separação da mídia em uma segunda máquina passa a se justificar quando a moderação local se tornar requisito, ou por volta de 2.000 usuários por dia — o que ocorrer primeiro.

Como ler os números

Cada valor deste documento está marcado pela origem. A distinção é relevante: decisões de infraestrutura costumam falhar quando estimativa é tratada como medição.

M Medido — lido do código, da configuração ou do ambiente. E Estimado — derivado de referência conhecida; precisa ser confirmado na máquina.

Estado da medição

O consumo de memória dos quatro serviços foi medido em 21/08/2026 no ambiente de homologação, com três amostras. Permanecem estimados apenas o worker de e-mail, ausente daquele ambiente, e a mídia com a moderação desligada. Os comandos usados, para repetir a medição:

Comandos de leitura, sem efeito colateral.
O que	Comando
Memória e CPU reais	`docker stats --no-stream az-backend-stg-v3 az-chat-backend-stg az-media-backend-stg az-dash-stg`
Folga da máquina	`nproc && free -h && df -h /`
Tamanho dos modelos de IA	`docker exec az-media-backend-stg du -sh /root/.cache/huggingface`
Custo real de uma moderação	Subir com `MODERATION_ENABLED=true`, publicar um vídeo e ler o tempo no log `[moderation]`

O tempo de uma inferência (~0,4 s) segue estimado e sustenta as tabelas de carga da seção 3 — é o próximo valor a confirmar.

1 · O que cada serviço consome

Memória

O teto é o que o gerenciador de processos aceita antes de reiniciar; o uso foi medido em 21/08/2026 no ambiente de homologação.
Serviço	Teto configurado	Uso esperado	Observação
Servidor principal	1 GB M	131 MB M	364 endpoints e 13 consumidores de fila. Usa 13% do teto.
Worker de e-mail	512 MB M	80–140 MB E	Processo separado, ausente do ambiente medido.
Dashboard	sem teto M	165 MB M	Sem limite declarado no gerenciador de processos.
Chat	512 MB M	38 MB M	O mais leve dos quatro. Usa 7% do teto.
Mídia — sem moderação	2 GB M	150–250 MB E	Só orquestra o envio para a Cloudflare.
Mídia — com moderação	2 GB M	1.984–2.535 MB M	Dois modelos de IA residentes. Acima do teto configurado.

Alerta — o teto configurado está abaixo do uso real

O gerenciador de processos reinicia a mídia ao ultrapassar 2 GB. A medição com moderação local ativa registrou até 2.535 MB — cerca de 487 MB acima do teto.

Em homologação isso não aparece, porque lá os serviços rodam em contêineres sem limite de memória. Em produção, onde o gerenciador de processos aplica o limite, o serviço seria encerrado e reiniciado a cada moderação — possivelmente em laço, já que os modelos são recarregados a cada subida.

Correção necessária antes de ligar a moderação local em produção: elevar o teto da mídia para 3 GB, ou executar a moderação pela Workers AI, que dispensa os modelos locais.

Observação central

Com a moderação local ativa, a mídia ocupa de 1.984 a 2.535 MB — contra 131 MB do servidor principal, 165 MB do dashboard e 38 MB do chat. Ela responde sozinha por 84% da memória usada pelos quatro serviços, e esse consumo independe do número de usuários: os modelos ficam residentes mesmo sem ninguém publicando. É ela, e não o tráfego, que decide o tamanho da máquina.

Disco

Cada serviço mantém 2 versões publicadas ao mesmo tempo — por isso o total dobra.
Serviço	Dependências	Build	× 2 versões
Servidor principal	780 MB M	13 MB M	1,6 GB
Dashboard	606 MB M	7,8 MB M	1,2 GB
Chat	407 MB M	~2 MB M	0,8 GB
Mídia	1,5 GB M	~2 MB M	3,0 GB
Cache dos modelos de IA	baixado no primeiro uso		0,4–1,0 GB E
Sistema e registros	—		~5 GB E
Total			~12 GB de 80

Das dependências da mídia, 956 MB são só a biblioteca de IA M — dois terços do peso do serviço. E o disco não cresce com o uso: fotos e vídeos vão direto para o armazenamento da Cloudflare, não ficam no servidor.

Processamento

Pico de CPU observado durante a publicação de uma mídia com moderação ativa. Em contêiner, 100% equivale a um núcleo inteiro.
Serviço	Em repouso	Durante a moderação	Em máquina de 2 núcleos
Mídia	0,02% M	115% M	57% da máquina
Servidor principal	0,17% M	8% M	4%
Chat	0,12% M	0,16% M	< 1%
Dashboard	0,00% M	0,00% M	—

Atenção — a análise local usa mais de um núcleo

A moderação não está limitada a um núcleo: o tempo de execução dos modelos ultrapassa 100%, o que significa processamento paralelo em mais de um núcleo. Numa máquina de dois, isso consome mais da metade da capacidade enquanto durar.

Nenhum limite de threads está configurado M — nem no código, nem no contêiner —, então a biblioteca usa todos os núcleos disponíveis. Definir OMP_NUM_THREADS=1 restringe a análise a um núcleo: cada mídia demora mais, mas deixa de competir com o restante do sistema. É a mitigação mais barata disponível.

Fora esse intervalo, nenhum dos quatro consome CPU de forma contínua — todos ficam ociosos entre requisições. As duas exceções são pontuais:

Moderação de mídia — cada foto passa por 2 análises, cada vídeo por 10 M. Uma foto ocupa ~0,8 s de CPU; um vídeo, ~4 s E.
Relatórios da dashboard — 20 consultas SQL escritas à mão e 14 contagens M. O peso cai no banco de dados, que fica em outra máquina, não na VM.

2 · O cenário das quatro juntas

É o arranjo previsto pelo plano de virada original: somar mídia e chat 3.0 ao servidor que já roda o principal, a dashboard e o chat antigo.

Soma de memória na máquina atual — 2 núcleos, 8 GB, 80 GB.
Cenário	Memória somada	Com sistema (~400 MB)	Folga em 8 GB	Veredito
Sem moderação local	0,5–0,7 GB	0,9–1,1 GB	6,9–7,1 GB	Confortável
Com moderação local	2,3–2,9 GB	2,7–3,3 GB	4,7–5,3 GB	Cabe

Conclusão

Cabe nos dois casos. No pior cenário sobram pelo menos 4,7 GB livres e o disco permanece em 15% de uso. Considerada apenas a capacidade da máquina, o arranjo atual seria suficiente — ressalvado o teto por processo tratado na seção 1.

O que a soma de memória não revela:

Uma publicação derruba os quatro. Todos rodam em processo único, sem cópia de reserva. Publicar o servidor principal tira o chat e a mídia do ar junto, por alguns segundos.
A rajada da moderação. Um vídeo ocupa ~4 s de CPU, que em 2 núcleos é metade da máquina. Acontece pouco — com 500 usuários e 30% publicando, 0,35% do tempo — quando coincide com um checkout, porém, o usuário aguarda.
A margem some junto. Os quatro crescem ao mesmo tempo. Uma máquina compartilhada atinge o limite de todos ao mesmo tempo, e a separação passa a ser urgência em vez de escolha.

3 · A carga por volume de usuários

O modelo abaixo parte das premissas declaradas a seguir. Todos os números das tabelas derivam delas.

Sessões por usuário: 1,5
Requisições por sessão: 25
Concentração no pico: 20%
Publicam conteúdo: 5–30%

Tráfego

Derivado das premissas acima.
Usuários/dia	Sessões	Requisições/dia	Média por segundo	Pico por segundo	Conexões de chat no pico
100	150	3.750	0,04	0,21	~20
300	450	11.250	0,13	0,62	~60
500	750	18.750	0,22	1,04	~100

Ordem de grandeza

1 requisição por segundo no pico. Um único núcleo moderno atende centenas disso com folga. Nesse patamar, o tráfego HTTP simplesmente não é um fator de dimensionamento — e as 100 conexões de chat somam menos de 4 MB de memória.

Moderação

Carga de processamento da análise automática, por volume e taxa de publicação.
Usuários/dia	Publicam	Publicações/dia	Análises/dia	CPU/dia	% do dia
100	5%	5	30	12 s	0,01%
100	15%	15	90	36 s	0,04%
100	30%	30	180	72 s	0,08%
300	5%	15	90	36 s	0,04%
300	15%	45	270	108 s	0,12%
300	30%	90	540	216 s	0,25%
500	5%	25	150	60 s	0,07%
500	15%	75	450	180 s	0,21%
500	30%	150	900	360 s	0,42%

Mesmo no pior caso da tabela, a moderação ocupa seis minutos de processamento em vinte e quatro horas. Ela não é um problema de volume — é um problema de memória fixa e de latência pontual.

A camada local é executada sempre

Ajustar a faixa de dúvida para que tudo seja encaminhado ao modelo de visão remoto não elimina o custo local: é a análise da camada 1 que produz a pontuação usada para decidir o encaminhamento, e ela roda antes de qualquer escalonamento M. A medição confirma — com o encaminhamento total ativo, o pico de 115% de CPU permanece, porque a chamada remota é espera de rede, não processamento.

Nessa configuração somam-se os dois custos: o processamento local de todas as mídias e a chamada remota de todas elas. Executar apenas a camada remota exige um caminho no código que dispense a análise local — inexistente hoje.

Limite de escala da moderação local

Projeção com 30% publicando — o cenário mais pesado.
Usuários/dia	Publicações/dia	CPU na hora de pico	Ocupação de 1 núcleo
100	30	14 s	0,4%
500	150	72 s	2,0%
1.000	300	144 s	4,0%
5.000	1.500	720 s	20,0%
20.000	6.000	2.880 s	80,0%
50.000	15.000	7.200 s	200%

Só perto de 20 mil usuários por dia um núcleo inteiro fica ocupado na hora de pico — patamar muito acima do horizonte atual. A moderação local é, portanto, uma questão de arquitetura e de custo de memória, não de capacidade de processamento.

4 · As três topologias

Tudo numa máquina só

Serve hoje

Máquina única

Servidor principal · dashboard · chat · mídia
2,7–3,3 GB de RAM com moderação · ~12 GB de disco

A favor: custo zero adicional, nada para migrar, e o banco de dados fica igualmente distante de todos os serviços — nenhuma consulta cruza a internet a mais do que já cruza.

Contra: publicar qualquer serviço interrompe os quatro. A rajada da moderação toma metade da máquina por alguns segundos. E não há para onde crescer sem trocar a máquina inteira.

Veredito

Suficiente com a moderação desligada ou terceirizada, e aceitável com moderação local no volume atual. Atende quando a prioridade é não ampliar a infraestrutura.

Servidor principal sozinho, os outros três juntos

Não compensa

Máquina 1

Servidor principal
0,6–0,7 GB de RAM · ~2 GB de disco

Máquina 2

Dashboard · chat · mídia
2,5–3,1 GB de RAM · ~10 GB de disco

A favor: o servidor principal — que atende o usuário final — fica completamente protegido de qualquer coisa que os outros façam.

Contra: desloca o dashboard e o chat sem necessidade. Ambos são leves e de consumo previsível. Além disso, o peso real do dashboard não recai sobre a máquina: são as 20 consultas SQL que ele executa, e elas caem no banco de dados, que fica em outro servidor. Mudar o dashboard de máquina não altera a carga do banco.

Veredito

Exige duas máquinas e alcança o mesmo resultado da opção C, que separa apenas o que tem perfil distinto. O ganho adicional sobre C não compensa deslocar dois serviços a mais.

Mídia isolada, os outros três juntos

Melhor separação

Máquina 1

Servidor principal · dashboard · chat
0,8–0,9 GB de RAM · ~9 GB de disco

Máquina 2

Mídia
2,3–2,9 GB de RAM · ~4 GB de disco

A favor: isola a única fonte de variação de carga. A mídia é o único serviço com perfil distinto dos demais — rajadas de processamento, 1,5 GB de dependências e modelos de IA residentes em memória. Os outros três são leves, previsíveis e coexistem sem interferência.

A assimetria medida é expressiva: a máquina 1 fica abaixo de 1 GB, enquanto a mídia sozinha pede quase 3 GB. Isso permite dimensionar cada lado pelo consumo real, em vez de somar tudo no maior denominador.

Contra: duas máquinas a administrar, dois certificados e dois executores de publicação. A mídia passa a se comunicar com o servidor principal pela rede — o que já ocorre hoje por meio da fila de mensagens, externa a ambas.

Veredito

A melhor das três quando a separação for necessária. Isola o que tem perfil distinto, mantém agrupado o que é semelhante e permite dimensionar cada lado conforme a carga real.

5 · Quanta máquina cada cenário pede

Requisitos derivados das seções anteriores. A regra usada: memória com 50% de folga sobre o pico esperado, disco com o dobro do ocupado, e núcleos suficientes para a rajada de moderação não tomar a máquina inteira.

Requisitos por topologia. Válidos para os três volumes (100, 300 e 500 usuários/dia) — nessa faixa o tráfego não altera o dimensionamento.
Topologia	Máquina	Moderação	Núcleos	Memória	Disco
A · tudo junto	Única	terceirizada	2	4 GB	40 GB
A · tudo junto	Única	local	2	8 GB	60 GB
B · principal isolado	Máquina 1	—	2	4 GB	40 GB
B · principal isolado	Máquina 2	local	2–4	8 GB	40 GB
C · mídia isolada	Máquina 1	—	2	4 GB	40 GB
C · mídia isolada	Máquina 2	local	2–4	4–8 GB	40 GB
Máquina atual, para comparar		—	2	8 GB	80 GB

A máquina atual já atende

2 núcleos, 8 GB e 80 GB cobrem qualquer linha desta tabela, inclusive o cenário mais pesado — tudo junto com moderação local, que soma 3,3 GB medidos. Não existe, nos números, um caso em que o hardware seja insuficiente para 500 usuários por dia. O que precisa mudar não é a máquina, e sim o teto por processo da mídia.

Quanto ao custo: os requisitos acima situam-se nas faixas mais baratas de qualquer provedor — máquinas de 2 a 4 núcleos com 4 a 8 GB. Os valores vigentes devem ser conferidos junto ao provedor E. Duas máquinas pequenas na topologia C tendem a custar próximo de uma única máquina intermediária: a comparação pertinente não é entre uma máquina e nenhuma, e sim entre duas pequenas e uma média.

Um ajuste que independe da topologia

O número de conexões que cada serviço abre com o banco é calculado automaticamente a partir dos núcleos da máquina — núcleos × 2 + 1 M, porque nenhum dos serviços define isso explicitamente.

Aumentar os núcleos amplia automaticamente as conexões ao banco. Com quatro serviços apontando para o mesmo Postgres, o limite deve ser fixado por serviço antes de qualquer troca de máquina; caso contrário, o gargalo apenas muda de lugar.

6 · Execução sem servidor: por que não se aplica

O modelo de execução sem servidor atende bem a muitos projetos. O que o inviabiliza neste caso é o formato dos serviços — três diferenças que independem de preço.

O que cada serviço precisa que o modelo serverless não oferece bem.
Necessidade	Onde aparece	Por que é um problema
Processo sempre acordado	Chat: conexões abertas e consumidor de fila. Mídia: consumidor e tarefa diária às 3h M	Container que hiberna não consome fila nem dispara tarefa agendada. Manter ligado 24h anula a economia do modelo.
Exatamente uma instância	Mídia — a documentação do serviço afirma isso explicitamente M	Duas cópias significam duas tarefas de exclusão às 3h e dois consumidores disputando a fila.
Estar perto do banco	Todos. Banco e fila estão na Hetzner M	Computação na borda com dados na Hetzner faz cada consulta cruzar a internet. O dashboard, com 20 consultas por relatório, é o pior caso.

Soma-se o custo de reescrita: publicação, gestão de segredos, registros e o modelo de execução dos três serviços precisariam ser refeitos — enquanto o chat 3.0 permanece pronto e não publicado.

Uso atual da Cloudflare

R2 e Stream armazenam e entregam todas as fotos e vídeos — razão pela qual o disco do servidor não cresce com o uso. O Workers AI já opera a segunda camada da moderação. A recomendação da seção 7 amplia esse uso: transferir toda a moderação para lá elimina a maior fonte de consumo de memória do sistema.

7 · Recomendação

Ações recomendadas, em ordem, com o gatilho de cada uma.
Quando	O quê	Por quê
Agora	Manter os quatro na máquina atual e publicar o chat 3.0 e a mídia nela.	Cabe com folga. Ampliar a infraestrutura agora resolveria um problema que os números não indicam.
Agora	Limitar a análise local a um núcleo e elevar o teto de memória da mídia para 3 GB.	Impede que a moderação tome mais da metade da máquina e que o processo seja reiniciado por estouro de memória. Custo zero, só configuração.
Antes de escalar	Fixar o limite de conexões ao banco por serviço.	Hoje varia automaticamente com o número de núcleos da máquina.
Curto prazo, em código	Criar um modo que dispense a análise local quando a moderação for feita apenas pelo modelo remoto.	Sem ele, encaminhar tudo ao modelo remoto soma os dois custos em vez de trocar um pelo outro.
Se a moderação local permanecer	Topologia C: mídia numa segunda máquina.	Um pico de 115% de CPU convivendo com o checkout é o principal argumento para separar.
Perto de 2.000 usuários/dia	Reavaliar com números medidos de novo.	Ponto em que a margem passa a reduzir de forma relevante.

Conclusão geral

A separação em duas máquinas é a arquitetura adequada — por isolamento, não por capacidade total. A medição reforça esse ponto: a mídia responde por 84% da memória e por um pico de 115% de CPU, enquanto os outros três somam menos de 350 MB e ficam praticamente ociosos. São perfis que não se parecem.

Até lá, o mesmo investimento tem retorno maior na réplica de leitura do banco de dados, que trata um problema já existente e que a troca de máquina não resolve.