Arquitetura Multi-Servidor: Separação de Responsabilidades

Este artigo explica como nossa infraestrutura utiliza servidores especializados para alcançar escalabilidade, confiabilidade e desempenho através da separação de responsabilidades.

O Problema: Limitações do Servidor Monolítico

Executar tudo em um único servidor causa:

• Contenção de recursos: O servidor web compete com o serviço de busca por CPU/memória

• Dificuldade de escalonamento: Não é possível escalar componentes de forma independente

• Ponto único de falha: Um servidor fora do ar = sistema inteiro fora do ar

• Ineficiência de custos: Não é possível otimizar tipos de instância por carga de trabalho

• Risco de implantação: Implantar um componente afeta todos os outros

Precisamos de separação de responsabilidades em múltiplos servidores.

A Solução: Funções Especializadas de Servidor

Executamos servidores especializados, cada um otimizado para sua carga de trabalho:

graph TB
    subgraph prod[Servidor de ERP de Produção]
        erp[Gerenciamento Interno
RH, Finanças, Manufatura
Disponibilidade 24/7
Armazenamento e e-mail compartilhados]
    end
    
    subgraph web[Servidor do Site Público]
        www[Site Público
Catálogo de produtos, blog
Disponibilidade 24/7
Atrás de CDN]
    end
    
    subgraph dev[Servidor de Desenvolvimento/Staging]
        devenv[Dev & Staging
Campanhas de e-mail
Desliga à noite/finais de semana]
    end
    
    subgraph search[Servidor do Serviço de Busca]
        searchsvc[Busca Vetorial
Extração de filtros
Buscas relacionadas
Disponibilidade 24/7]
    end
    
    subgraph cache[Servidor de Cache - Valkey]
        valkey[Índices RediSearch
Embeddings de consulta
Autocompletar
Disponibilidade 24/7]
    end
    
    www --> searchsvc
    searchsvc --> valkey

Por Que Separar os Servidores?

1. Isolamento de Recursos

Cada servidor executa um tipo de carga de trabalho:

Servidor Web: Otimizado para manipulação de requisições HTTP

• Alta largura de banda de rede

• CPU moderada

• Memória moderada

• Disco rápido para cache

Serviço de Busca: Otimizado para operações vetoriais

• Alta CPU (similaridade de cosseno)

• Alta memória (cache de embeddings)

• Baixo I/O de disco

Servidor de Cache: Otimizado para acesso à memória

• Memória muito alta

• Baixa CPU

• Rede rápida

Benefício: Nenhuma contenção de recursos entre cargas de trabalho.

2. Escalonamento Independente

Podemos escalar cada componente independentemente:

• Tráfego alto? Adicione mais servidores web atrás do balanceador de carga.

• Busca lenta? Atualize a CPU do servidor de busca ou adicione réplicas.

• Faltas no cache? Aumente a memória do servidor de cache.

• Benefício: Escale apenas o que precisa ser escalado, não tudo.

3. Isolamento de Falhas

As falhas são contidas:

Serviço de busca fora do ar? O site ainda serve resultados em cache.

Servidor de cache fora do ar? O serviço de busca computa sem cache (mais lento, mas funcional).

Servidor web fora do ar? O ERP interno não é afetado.

Benefício: Falhas parciais não se propagam para todo o sistema.

4. Segurança na Implantação

Implantamos através de ambientes:

Desenvolvimento → Teste de mudanças com ferramentas de depuração

Staging → Teste em ambiente semelhante à produção

Produção → Implante com confiança

Benefício: Capture problemas antes que cheguem aos usuários.

5. Otimização de Custos

Otimizamos custos por servidor:

• Servidor de desenvolvimento: Desliga à noite/finais de semana (redução de 50% no custo)

• Servidores apenas IPv6: Sem custos de IP elástico (economia de $5/mês por instância)

• Instâncias dimensionadas corretamente: Pague apenas pelos recursos necessários por carga de trabalho

• Benefício: Custos de infraestrutura mais baixos sem sacrificar desempenho.

Fluxo de Dados Entre Servidores

Entender como os dados fluem ajuda a explicar por que a separação importa:

Fluxo de Requisição do Usuário

Requisição de Página de Produto:

sequenceDiagram
    participant Usuário
    participant CDN
    participant Web as Servidor Web
    participant Search as Serviço de Busca
    participant Cache as Servidor de Cache
    
    Usuário->>CDN: Requisição de página de produto
    CDN->>CDN: Verifica cache
    alt Acerto no cache
        CDN->>Usuário: Serve página em cache
    else Falha no cache
        CDN->>Web: Encaminha requisição
        Web->>Search: Obtém produtos relacionados
        Search->>Cache: Consulta embeddings
        Cache->>Search: Retorna resultados
        Search->>Web: Produtos relacionados
        Web->>CDN: Página renderizada
        CDN->>CDN: Cache da resposta
        CDN->>Usuário: Serve página
    end

Fluxo de Consulta de Busca:

sequenceDiagram
    participant Usuário
    participant Web as Servidor Web
    participant Search as Serviço de Busca
    participant Cache as Servidor de Cache
    
    Usuário->>Web: Envia consulta de busca
    Web->>Search: Encaminha consulta
    Search->>Search: Extrai filtros
    Search->>Search: Computa embedding
    Search->>Cache: Busca vetorial
    Cache->>Search: Resultados ranqueados
    Search->>Web: Produtos correspondentes
    Web->>Usuário: Renderiza resultados

Benefício: Cada servidor faz o que está otimizado para fazer.

Estratégia de Armazenamento Por Servidor

Servidores diferentes usam estratégias de armazenamento diferentes:

Servidor Web

Arquivos estáticos no S3: Imagens, CSS, JS servidos do S3

• Alta disponibilidade

• Nenhum uso de disco local

• Amigável a CDN

Cache local: Nginx armazena em cache páginas renderizadas

• Acesso repetido rápido

• Invalidação automática

Serviço de Busca

Arrays NumPy: Embeddings de produtos armazenados como arrays binários

• Operações vetoriais rápidas

• Mapeados em memória para eficiência

• 65K produtos × 768 dimensões = ~190 MB

Arquivos JSON: Mapeamentos de filtros, tabelas de frases

• Legíveis por humanos

• Fáceis de atualizar

• Tamanho pequeno (<10 MB)

Servidor de Cache

Valkey (Redis): Embeddings de consulta, consultas populares, autocompletar

• Em memória para velocidade

• RediSearch para índices vetoriais

• Persistência para durabilidade

Por que armazenamento diferente?

• NumPy: Otimizado para matemática vetorial (similaridade de cosseno)

• JSON: Otimizado para edição humana (regras de filtro)

• Valkey: Otimizado para buscas chave-valor (cache de consulta)

Arquitetura de CDN

O site público fica atrás de uma Rede de Entrega de Conteúdo:

O Que É Armazenado em Cache

Ativos estáticos (TTL longo):

• Imagens, CSS, JavaScript

• Fontes, ícones

• Em cache por 1 ano

Páginas de produto (TTL médio):

• Descrições de produtos

• Especificações

• Em cache por 1 hora

Páginas de consulta (TTL curto):

• Resultados de busca

• Combinações de filtros

• Em cache por 5 minutos

Não armazenado em cache:

• Conteúdo específico do usuário

• Endpoints de API

• Busca dinâmica

Por Que o CDN Importa

• Latência global: Localizações de borda servem conteúdo mais perto dos usuários

• Proteção da origem: O CDN absorve picos de tráfego, protege o servidor de origem

• Mitigação de DDoS: O CDN filtra tráfego malicioso antes que chegue à origem

• Redução de custos: Menos requisições à origem = custos de computação mais baixos

Pipeline de Implantação

Implantamos através de ambientes para capturar problemas cedo:

Ambiente de Desenvolvimento

Propósito: Iteração rápida com ferramentas de depuração Características:

• Recarregamento automático em mudanças de código

• Páginas de erro detalhadas

• Barra de ferramentas de depuração

• Sem cache

Benefício: Ciclo de feedback rápido para desenvolvedores.

Ambiente de Staging

Propósito: Teste semelhante à produção Características:

• Mesma configuração da produção

• Mesma configuração de servidor (Gunicorn, Nginx)

• Mesmo comportamento de cache

• Isolado dos dados de produção

Benefício: Capture problemas específicos da produção antes da implantação.

Ambiente de Produção

Propósito: Servir usuários reais Características:

• Otimizado para desempenho

• Cache completo habilitado

• Monitoramento e alertas

• Reinício automático em falhas

Benefício: Serviço estável e confiável.

Referências

Conceitos Técnicos

• Separação de Responsabilidades - Wikipedia

• Rede de Entrega de Conteúdo (CDN) - Wikipedia

• Escalonamento Horizontal - Wikipedia

• Similaridade de Cosseno - Wikipedia

Serviços AWS

• CloudFront - Documentação do CDN da AWS

• S3 - Documentação de armazenamento de objetos da AWS

• DynamoDB - Documentação do banco de dados NoSQL da AWS

Artigos Relacionados

• Arquitetura do Serviço de Busca - Detalhes do serviço de busca independente

• Estratégia de Embedding para SEO - Por que usamos all-mpnet-base-v2

• Correspondência de Produtos para SEO - Como a busca vetorial funciona

• Sistema de Tradução - Arquitetura de suporte a múltiplos idiomas

Resumo

Nossa arquitetura multi-servidor separa responsabilidades entre servidores especializados:

Servidor de ERP de Produção:

• Sistema de gerenciamento interno

• Disponibilidade 24/7

• Armazenamento e e-mail compartilhados

Servidor do Site Público:

• Site voltado ao cliente

• Disponibilidade 24/7

• Atrás de CDN com arquivos estáticos no S3

Servidor de Desenvolvimento/Staging:

• Ambientes de teste seguros

• Processamento de campanhas de e-mail

• Otimizado em custo (desliga à noite/finais de semana)

Servidor do Serviço de Busca:

• Busca por similaridade vetorial

• Extração de filtros

• Embeddings baseados em NumPy

Servidor de Cache (Valkey):

• Cache de embeddings de consulta

• Índices vetoriais RediSearch

• Ranqueamento de consultas populares

Benefícios Principais:

• ✅ Isolamento de recursos: Nenhuma contenção entre cargas de trabalho

• ✅ Escalonamento independente: Escale apenas o que precisa ser escalado

• ✅ Isolamento de falhas: Falhas não se propagam

• ✅ Segurança na implantação: Teste antes da produção

• ✅ Otimização de custos: Instâncias dimensionadas corretamente, agendamentos de energia

• ✅ Desempenho: Cache de CDN, estratégias de armazenamento especializadas

Esta arquitetura nos permite atender milhões de requisições enquanto mantemos alta disponibilidade, baixa latência e custos gerenciáveis.

---

← Voltar ao Índice da Documentação