AZ Docs — Infraestrutura

Antes de tudo: por que existem quatro serviços

O AZ Collections não é um sistema único. São quatro serviços separados, cada um dono de uma parte do produto, e é essa divisão que torna a questão do dimensionamento mais complexa do que “quanta máquina é preciso”.

Os quatro serviços e do que cada um é dono.
Serviço	De que é dono	Perfil de consumo
Servidor principal	Contas, feed, loja, checkout, pedidos e pagamentos.	Muitas rotas, consumo baixo e constante.
Chat	Conversa, negociação e propostas de troca.	Conexões abertas, consumo mínimo.
Dashboard	Administração interna e relatórios.	Leve na máquina; o peso cai no banco de dados.
Mídia	Fotos, vídeos, AZ Play e a moderação de conteúdo.	Descolado dos demais — modelos de IA na memória e rajadas de processamento.

Os três primeiros se parecem: respondem requisições, consomem pouco e ficam ociosos entre uma e outra. O serviço de mídia é diferente de todos — ele carrega modelos de inteligência artificial na memória e processa cada foto e cada vídeo antes de liberá-los. É de onde vem a maior parte do consumo medido neste documento, e é o que decide qual arranjo de servidores faz sentido.

Leitura recomendada antes desta análise

Boa parte do que se discute aqui — as duas camadas de moderação, por que o serviço roda em instância única, por que os arquivos não ocupam disco do servidor e como as filas ligam os serviços — está explicada em detalhe no documento do serviço de mídia. Para acompanhar os números das próximas seções sem lacunas, vale começar por ele:

Como o AZ Media funciona, de ponta a ponta

O serviço de chat, o segundo com desenho próprio, está descrito em Como o AZ Chat funciona.

Síntese

Memória, disco e tráfego — folgados

Nesses três aspectos, os quatro serviços cabem na máquina atual, inclusive com a moderação ligada. A memória somada fica entre 2,7 e 3,3 GB dos 8 GB disponíveis, 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.

Processamento — depende de como a moderação roda

Aqui a resposta muda conforme a configuração. Cada análise de conteúdo consome 115% de CPU — mais de um núcleo —, e o consumidor da fila aceita até dez análises simultâneas:

Moderação remota (sem a camada local): 2 núcleos sobram com folga.
Moderação local serializada, uma por vez e com um núcleo por análise: cabe, mas metade da máquina fica ocupada durante cada análise.
Moderação local como está hoje: não cabe. Bastam duas publicações simultâneas para ultrapassar a capacidade dos dois núcleos, em qualquer volume de usuários.

A conclusão, portanto, não é sobre o tamanho da máquina. O que precisa mudar são três configurações da mídia — limite de uma análise por vez, um núcleo por análise e teto de memória de 3 GB — e a decisão de manter ou não a camada local de análise. Nenhuma delas exige servidor novo.

Um segundo servidor continua sendo a arquitetura mais limpa, por isolamento: hoje qualquer publicação do servidor principal interrompe os quatro ao mesmo tempo. Mas isso é questão de robustez, não de capacidade — e não é urgente.

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

115% de CPU por publicação Mais de um núcleo. Em máquina de dois, 57% da capacidade.

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 corrigir três configurações da mídia: uma análise por vez, um núcleo por análise e teto de memória de 3 GB. Em seguida, avaliar a moderação sem a camada local. Se a qualidade servir, o consumo cai para 1,1 GB — 13% da máquina e nenhuma infraestrutura nova é necessária. Se não servir, a camada local — e só ela — vai para um contêiner sob demanda. A separação em duas máquinas fica reservada ao crescimento de volume, por volta de 2.000 usuários por dia.

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. Essa parcela é residente: os modelos ficam carregados mesmo sem ninguém publicando, e não crescem com o número de usuários. Cada análise em andamento consome memória adicional além dessa base — o que torna a concorrência relevante (seção 3).

É a moderação, e não o tráfego, que determina o consumo do conjunto. Isso não significa, porém, que a saída seja uma máquina maior: como mostram as seções 3 e 5, o mesmo hardware atende assim que a moderação passa a rodar de forma controlada.

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, a 115% de CPU M. A duração de cada análise ainda não foi medida 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 (8 GB). O processamento é tratado na seção 3 e tem resposta diferente.
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

Em memória, cabe nos dois casos. No pior cenário sobram pelo menos 4,7 GB livres e o disco permanece em 15% de uso.

Isso não significa que o arranjo atual funcione: o teto por processo da mídia está abaixo do uso real (seção 1) e o processamento tem resposta diferente da memória (seção 3). Memória é o aspecto em que há folga, não a conclusão geral.

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. Cada publicação consome 115% de CPU — mais de um núcleo. Em máquina de dois, é metade da capacidade; e o consumidor aceita até dez análises simultâneas, o que multiplica esse pico (seção 3).
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 cerca de seis minutos de processamento em vinte e quatro horas. O total diário, porém, não é o critério de dimensionamento: seis minutos distribuídos ao longo do dia são irrelevantes; seis minutos concentrados em uma rajada de publicações simultâneas travam a máquina.

O que dimensiona esta carga são três fatores, nenhum deles ligado ao volume diário: a memória residente dos modelos, a intensidade de cada análise (115% de CPU) e quantas chegam ao mesmo tempo — tratado a seguir.

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.

Concorrência: o fator que multiplica o pico

Os 115% correspondem a uma publicação. O consumidor da fila, porém, aceita até dez mensagens simultâneas e não aguarda cada uma terminar antes de iniciar a seguinte M. Dez pessoas publicando ao mesmo tempo viram dez análises concorrentes dentro do mesmo processo.

Demanda de processamento conforme o número de publicações simultâneas, em máquina de 2 núcleos (200% de capacidade).
Publicações simultâneas	Demanda de CPU	Situação
1	115%	Folgado — 57% da máquina
2	230%	Já ultrapassa a capacidade
5	575%	2,9× acima
10	1.150%	5,8× acima

Correção prioritária

Reduzir o limite de mensagens simultâneas para 1. As publicações passam a ser analisadas em série: a última espera mais, mas a máquina nunca sai do controle e os demais serviços seguem respondendo.

A moderação é assíncrona por natureza — a mídia já foi enviada e aguarda análise, sem ninguém esperando em tela. Serializar não piora a experiência; evita que uma rajada de publicações derrube o servidor inteiro. A memória também acompanha: cada análise concorrente aloca seus próprios dados, e o teto de 2 GB seria atingido bem antes das dez.

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%

A projeção acima pressupõe análises em série, uma de cada vez. Sob essa condição, só perto de 20 mil usuários por dia um núcleo inteiro ficaria ocupado na hora de pico.

A condição não se verifica hoje

Com o limite de dez mensagens simultâneas, a serialização não acontece: bastam duas publicações ao mesmo tempo para ultrapassar a capacidade de uma máquina de dois núcleos, em qualquer volume de usuários. O número de 20 mil só passa a valer depois de reduzir a concorrência para 1.

Serializada, a moderação local é uma questão de memória e arquitetura, não de capacidade de processamento.

4 · As três topologias

Tudo numa máquina só

Serve, com ajustes

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 análise de conteúdo toma mais da metade da máquina enquanto roda, e mais de uma publicação simultânea ultrapassa a capacidade total. Não há para onde crescer sem trocar a máquina.

Veredito

Atende com a moderação remota ou local serializada. Não atende na configuração atual, em que até dez análises podem começar juntas. Feitos os três ajustes da seção 7, é a opção certa 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.

Esta topologia pressupõe a camada local de análise

Os 2,3–2,9 GB da máquina 2 são quase inteiramente os modelos de IA. Sem a camada local, a mídia cai para cerca de 250 MB — e a topologia perde o motivo de existir, porque some a assimetria que a justifica. Decidir sobre a camada local vem antes de decidir sobre a separação.

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; a moderação, sim.
Topologia	Máquina	Moderação	Núcleos	Memória	Disco
A · tudo junto	Única	remota	2	4 GB	40 GB
A · tudo junto	Única	local, serializada	2 (4 confortável)	8 GB	60 GB
A · tudo junto	Única	local, como está hoje	Não dimensionável — o pico depende de quantas publicações chegam juntas
B · principal isolado	Máquina 1	—	2	4 GB	40 GB
B · principal isolado	Máquina 2	local, serializada	2	8 GB	40 GB
C · mídia isolada	Máquina 1	—	2	4 GB	40 GB
C · mídia isolada	Máquina 2	local, serializada	2	4 GB	40 GB
Máquina atual, para comparar		—	2	8 GB	80 GB

A máquina atual já atende

Em memória, a máquina atual cobre qualquer linha da tabela: o cenário mais pesado soma 3,3 GB medidos, contra 8 GB disponíveis. Em processamento, ela atende com a moderação remota ou serializada — mas não na configuração atual, em que dez análises podem começar juntas.

O que precisa mudar, portanto, não é a máquina: é o limite de concorrência, o teto de memória por processo e o número de threads por análise. Três configurações.

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 fora do servidor

Três alternativas costumam ser confundidas sob o mesmo nome. Elas se comportam de forma muito diferente diante desta carga.

Limites das três formas de executar código na Cloudflare.
Forma	Memória disponível	Serve para a análise local?
Worker (borda)	128 MB por execução	Não — os modelos pedem 2 a 2,5 GB
Container	1 a 12 GiB, conforme o tipo	Sim — 4 GiB acomodam com folga
Workers AI	não se aplica — modelo hospedado	Sim — é o que já executa a segunda camada

Worker na borda está fora

O limite de 128 MB por execução é vinte vezes menor que o necessário. Não é questão de otimização: modelos de visão não cabem nesse ambiente. O tamanho do pacote também impede — 10 MB comprimidos contra cerca de 250 MB só de pesos.

Container é adequado — para esta carga específica

Aqui é preciso separar duas coisas que costumam ser tratadas como uma só: o serviço de mídia e a camada de análise que roda dentro dele. O serviço precisa de processo sempre acordado — consome fila e tem tarefa agendada, como o chat. A camada de análise, não:

Executa sob demanda, apenas quando alguém publica.
Não guarda estado: entra a imagem, sai o veredito.
Tolera partida a frio — a mídia fica em análise, ninguém aguarda em tela.
Fica ociosa a maior parte do tempo, com o volume atual de publicações.

É o perfil em que a cobrança por uso trabalha a favor. Um tipo de 4 GiB comporta os modelos. O serviço de mídia continua no servidor, consumindo a fila e agendando suas tarefas; o que sai é apenas a análise, chamada por HTTP — como já acontece hoje com a Workers AI.

Por que os quatro serviços continuam fora dessa opção

O que cada serviço exige e o modelo sob demanda não oferece. Vale para os serviços inteiros, não para a camada de análise.
Necessidade	Onde aparece	Consequência
Processo sempre acordado	Chat: conexões e consumidor de fila. Mídia: consumidor e tarefa diária às 3h M	Instância que hiberna não consome fila nem dispara tarefa agendada.
Exatamente uma instância	Mídia — a documentação do serviço afirma isso explicitamente M	Duas cópias significam duas exclusões às 3h e dois consumidores disputando a fila.
Proximidade do banco	Todos. Banco e fila permanecem na Hetzner M	Execução na borda faz cada consulta cruzar a internet. O dashboard, com 20 consultas por relatório, é o pior caso.

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á executa a segunda camada da moderação, fora do servidor. O consumo medido de 2,5 GB e 115% vem inteiramente da primeira camada, que roda localmente.

7 · Recomendação

Ações recomendadas, em ordem, com o gatilho de cada uma.
Quando	O quê	Por quê
Imediato	Limitar a fila a uma análise por vez, restringir a análise a um núcleo e elevar o teto de memória da mídia para 3 GB.	Três configurações. Eliminam o cenário em que uma rajada de publicações trava a máquina e o processo é reiniciado por estouro de memória.
Em seguida	Avaliar a moderação sem a camada local, apenas com o modelo remoto.	É a pergunta que decide todo o resto. A camada local existe para poupar chamadas ao modelo remoto — cerca de 450 por dia neste volume. Manter 2,5 GB de memória e 115% de CPU para essa economia não se justifica.
Se a qualidade servir	Remover a camada local. Os quatro serviços permanecem na máquina atual.	O consumo cai para 1,1 GB — 13% da máquina. O pico de processamento desaparece, o teto deixa de ser problema e a concorrência da fila torna-se inofensiva.
Se a qualidade não servir	Mover apenas a camada local para um contêiner de 4 GiB na Cloudflare.	É a carga que se encaixa no modelo sob demanda: sem estado, esporádica e tolerante a partida a frio. Os outros três serviços continuam no servidor.
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.
Perto de 2.000 usuários/dia	Reavaliar a separação em duas máquinas.	Ponto em que a margem passa a reduzir de forma relevante.

Conclusão geral

O problema não é a quantidade de serviços na máquina: é um serviço com perfil incompatível com os demais. A mídia responde por 84% da memória e por um pico de 115% de CPU; os outros três somam menos de 350 MB e ficam praticamente ociosos.

E o consumo da mídia não vem do serviço — vem da camada local de análise. Removida ela, os quatro convivem usando 13% da máquina. A separação em duas máquinas continua sendo a arquitetura mais limpa, por isolamento de falha e de publicação, mas deixa de ter qualquer urgência.

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.