Quais São Os Sistemas

Entendendo quais são os sistemas no dia a dia técnico

A pergunta quais são os sistemas aparece com frequência em reuniões de arquitetura de software e em diagnósticos de infraestrutura, mas raramente recebe uma resposta útil. A maioria das pessoas começa listando categorias de livro didático: sistemas operacionais, sistemas embarcados, sistemas distribuídos. Isso não ajuda ninguém a decidir o que investigar num servidor que caiu às 3 da manhã. Eu trabalho com isso há anos e a primeira coisa que aprendi é que "sistema" não é um tipo de coisa, é uma relação entre coisas. Um banco de dados sozinho não é um sistema. Um banco de dados com um driver, uma fila de mensagens, um cache e um processo de manutenção que roda todo domingo às 2h é um sistema. A fronteira entre "componente" e "sistema" depende inteiramente de onde você corta o diagrama.

Como identificar quais são os sistemas na sua infraestrutura

O método prático que eu uso é o seguinte: desenha-se o fluxo de dados, não a hierarquia de servidores. Pegue uma requisição qualquer — uma autenticação de usuário, um processamento de pagamento, um job de importação de CSV — e rastreie cada hop que ela faz. Cada serviço que ela toca é um subsistema. Cada banco de dados, fila ou serviço de terceiros também conta. Num projeto meu recente, estávamos investigando latência alta num sistema de Notificações por Push. A equipe achava que o problema era o gateway do Firebase. Descobrimos, depois de trazar 47 requisições, que o gargalo era um serviço de validação de token que chamava uma API externa sem cache, e essa API tinha um limite de taxa não documentado. O Firebase estava perfeito. Nós passamos duas semanas caçando o problema errado porque tínhamos assumido que o sistema visível era o sistema principal. Este é um ponto que poucos mencionam: o sistema que você vê na interface é raramente o sistema mais importante. A maior parte do tempo e da complexidade mora nos sistemas invisíveis — filas, jobs, reconciliações, logs, métricas.

Sistemas operacionais: o básico que todo mundo esquece

Sim, existem sistemas operacionais. Linux, Windows, macOS, FreeBSD. Mas a distinção relevante para quem opera infraestrutura não é o nome, é o modelo de gestão de recursos. Linux usa cgroups e namespaces para isolamento. Windows usa containers HCS e Hyper-V. Ambos resolvem o mesmo problema — limitar quanto CPU, memória e I/O um processo pode usar — mas com filosofias diferentes que impactam diretamente o tuning de performance. Quando eu entro num servidor Linux novo, os primeiros comandos que executo são:

• cat /proc/sys/vm/swappiness — valor padrão é 60 em muitas distribuições, o que é demais para cargas de trabalho com banco de dados. Eu ajusto para 10.
• vm.overcommit_memory — o padrão 0 causa surpresas desagradáveis quando um processo grande pede memória e o kernel decide que não tem como entregar. Para bancos de dados, 2 é mais seguro.
• fs.file-max e fs.nr_open — limites de descritores de arquivo que travam aplicações concurrentes sem nenhum erro óbvio no log.

Esses ajustes não aparecem em tutoriais genéricos. Eles surgem quando algo para de responder e o top mostra que o processo está em estado "D" (bloqueado em E/S). A diferença fundamental entre um sistema embarcado e um sistema rodando em datacenter não é o hardware, é a garantia de tempo. Sistemas embarcados críticos — controladores de freio, marcapasso, sistemas de aviação — exigem determinismo. Se uma tarefa não terminar dentro de um deadline estrito, o sistema está falhando, mesmo que ele continue rodando. Sistemas de servidor, por outro lado, otimizam throughput. Um servidor web pode atrasar uma requisição em 500ms e ninguém vai reclamar. Um controlador de freio que atrasar 500ms tem consequências diferentes.

Eu já configurei um sistema embarcado baseado em ESP32 para monitoramento ambiental em uma fábrica. A limitação real não era o processador — era a energia. O dispositivo precisava funcionar por 18 meses com uma bateria de lítio, enviando dados a cada 30 segundos. O workaround que funcionou foi colocar o chip em modo light sleep entre transmissões e usar o watchdog timer para recuperar de travamentos, que aconteciam mais frequentemente do que o esperado em ambientes com interferência eletromagnética de motores industriais.

Sistemas distribuídos: onde as coisas dão errado de forma interessante

Um sistema distribuído é aquele em que a falha de um componente não paralisa o todo. Isso parece uma vantagem. Na prática, é uma fonte permanente de dor de cabeça porque introduz indeterminismo. As três propriedades que você precisa entender antes de construir qualquer sistema distribuído são capturadas pelo teorema CAP: consistência, disponibilidade e tolerância a particionamento. Você escolhe dois. Sempre. Não existe saída mágica. O erro mais comum que eu vejo é Timezone. Horários em sistemas distribuídos usam UTC internamente, mas quando alguém converte para horário local para exibição, bugs aparecem. Eu já passei 6 horas investigando um problema de dados duplicados que era, na verdade, um caso em que dois write-ahead logs de regiões diferentes tinham timestamps sobrepostos porque um deles tinha mudado para horário de verão e o outro não.

O workaround que adotei foi usar vector clocks para ordenação causal em vez de depender de timestamps. É mais complexo de implementar, mas elimina a ambiguidade que causava os duplicados.

Sistemas de banco de dados: relacionais e não relacionais

A distinção entre SQL e NoSQL é mais sobre modelo de dados do que sobre tecnologia. PostgreSQL com JSONB faz muita coisa que tradicionalmente associam a MongoDB. Redis com suas estruturas de dados avançadas se sobrepõe a funcionalidades de column-store databases em certos cenários. O que realmente importa na escolha é o padrão de acesso, não o tipo de banco. Se suas consultas são majoritariamente leituras pontuais por chave primária, um key-value store como Redis ou DynamoDB vai performar muito bem. Se você precisa de join complexo e consistência transacional forte, PostgreSQL ou Oracle são caminhos mais seguros. Eu tive um caso específico onde migrei um sistema de inventário de PostgreSQL para CockroachDB porque precisávamos de multi-region active-active com consistência forte. A migração em si levou 3 dias usando o pg_dump e ajuste fino nos índices. O problema real foi que algumas queries que rodavam em 2ms no PostgreSQL passaram a levar 800ms no CockroachDB porque o otimizador de queries do CockroachDB tem um comportamento diferente com estatísticas desatualizadas. A solução foi rodar ANALYZE em todas as tabelas e reescrever três queries que dependiam de order by com limit para usar window functions de forma mais eficiente.

Sistemas de arquivos: o que ninguém olha até dar problema

EXT4, XFS, NTFS, ZFS, APFS. Cada um tem características distintas que importam para carga de trabalho específica. XFS é excelente para arquivos grandes e paralelismo. ZFS oferece integridade de dados com checksum mas tem overhead de memória significativo. NTFS é aceitável mas tem limitações sérias em permissões POSIX quando você precisa rodar serviços Linux em cima do WSL. Uma armadilha comum em Linux é o comportamento de named pipes e filesystems efêmeros como /tmp. Em containers Docker, /tmp é normalmente tmpfs, o que significa que arquivos grandes ali somem ao reiniciar o container. Se seu sistema depende de temp files para processamento, isso vai te surpreender. O ajuste prático que eu recomendo para qualquer sistema Linux de produção: verifique o mount option no-atime em sistemas de arquivos que não precisam de acesso timestamps. Isso reduz writes desnecessários no disco e melhora performance em cargas de I/O intenso. A economia é pequena por operação mas se acumula rapidamente em sistemas com milhões de acessos por dia.

Sistemas de mensageria e eventos

Kafka, RabbitMQ, AWS SQS, Google Pub/Sub. Cada um resolve problemas diferentes. Kafka é sobre retenção de eventos e replay. RabbitMQ é sobre roteamento flexível e garantias de entrega. SQS é sobre simplicidade e escala automática. O problema que mais causa dor de cabeça em sistemas de mensageria é o "dead letter queue invisível". Quando uma mensagem falha ao ser processada, ela pode ir para uma DLQ sem ninguém configurar um monitoramento. Eu já perdi dois dias um problema de dados inconsistentes porque mensagens de confirmação de pagamento estavam sendo descartadas silenciosamente numa DLQ que ninguém sabia que existia. A regra prática: monitore sempre o tamanho da fila de erros, não apenas o throughput de sucesso. Uma fila de sucesso saudável com uma DLQ crescendo é um sistema doente.

Sistemas de observabilidade

Métricas, logs, traces. Estes são os três pilares de qualquer sistema moderno que precisa ser investigado quando algo quebra. Prometheus + Grafana para métricas, Loki ou ELK para logs, Jaeger ou Tempo para traces. O erro mais comum é coletar tudo e não saber o que procurar quando o alarme tocar. A abordagem que funciona é definir os SLIs (Service Level Indicators) antes de instrumentar. Latência p99, taxa de erro, saturação de recursos. Coletar métricas sem saber qual SLI elas representam é ruido. Num sistema meu, implementamos redutores de log baseados em sampling adaptativo: quando a taxa de erro sobe acima de 1%, todos os logs do serviço afetado são preservados em vez de amostrados. Isso reduziu o custo de storage em 70% sem perder visibilidade nos momentos que realmente importam.

Convergência: como saber quais são os sistemas num projeto real

No final do dia, a pergunta "quais são os sistemas" se resume a mapear fronteiras de responsabilidade. Um sistema tem entrada, processamento, saída e estado. Se você não consegue identificar esses quatro elementos num componente, ele provavelmente não é um sistema independente — é parte de outro sistema maior. A ferramenta prática que eu uso é o mapa de dependência de serviços. Listam-se todos os serviços, suas interfaces públicas, e as chamadas síncronas e assíncronas entre eles. Cada ciclo no grafo é um sinal de acoplamento problemático. Cada serviço sem monitoramento é um risco operacional. Isso é tudo. A teoria é simples, a execução é onde as surpresas aparecem.