Computação

Computação é onde o seu código roda: os serviços que recebem uma requisição, aplicam as regras de negócio e chamam armazenamento, mensageria e provedores externos. As perguntas de projeto são sempre as mesmas — quanto estado ele guarda, como ele escala, quanto tempo uma requisição pode levar e o que acontece quando uma dependência fica lenta? Tratadores de requisição sem estado escalam adicionando réplicas; trabalho longo ou pesado vai para workers em segundo plano; trabalho curto e com picos pode ir para serverless; e algumas capacidades (identidade, busca, notificações, analytics) são tão comuns que viram serviços dedicados.

No BoxOffice, catalog, inventory e order são app servers; e-mails e ingressos em PDF são gerados por workers; os lembretes de "os portões abrem em 1 hora" são disparados por um scheduler; o login é o serviço auth; a busca de eventos é o serviço search; e toda visualização de página e compra alimenta o analytics.

flowchart LR
    GW[API Gateway] --> AUTH[Auth Service]
    GW --> APP[App Server<br/>catalog / order]
    GW --> SR[Search]
    APP --> Q[(Fila)]
    SCH[Scheduler] --> Q
    Q --> W[Worker]
    W --> N[Notifications]
    APP -. eventos .-> AN[Analytics]

App Server

O que é. O processo que executa o código do seu serviço — um serviço catalog em Spring Boot, um assistant em FastAPI — tratando requisições síncronas: interpretar, autorizar, rodar as regras de negócio, chamar o banco ou outros serviços, responder. A propriedade-chave de projeto é ser sem estado (stateless): nenhuma sessão ou dado do usuário guardado na memória local entre requisições, de modo que qualquer réplica possa atender qualquer requisição e réplicas possam ser adicionadas, removidas ou substituídas à vontade.

Quando usar.

• Para toda API síncrona pela qual o usuário espera: navegar por eventos, reservar assentos, fazer um pedido.
• Comece com um único artefato implantável (um monólito modular) e divida em serviços só ao longo de fronteiras claras (bounded contexts) ou quando as necessidades de times e de escala divergirem.
• Escale horizontalmente atrás de um load balancer; faça autoescala por CPU, taxa de requisições ou latência.

Quando não usar (ou cuidado).

• Não faça trabalho lento dentro da requisição (enviar e-mails, gerar PDFs, chamar um provedor lento sem timeout): leve-o para um worker.
• Não guarde em memória estado que precise sobreviver à réplica (sessões, carrinhos, contadores de rate limit): use um cache ou um banco de dados.
• Cada chamada síncrona a outro serviço adiciona latência e um ponto de falha; cadeias longas de serviços multiplicam os dois.

Números-chave.

Modos de falha.

• Esgotamento do pool de threads — uma dependência lenta segura todas as threads enquanto a CPU está ociosa; o serviço para de responder → timeouts, circuit breakers, bulkheads (cenário cascading-failure).
• Sobrecarga depois do joelho — com ρ → 1 o atraso de fila explode → autoescala com folga, descarte de carga, rate limiting.
• Vazamento de memória — a capacidade cai devagar ao longo de horas → testes soak, reinícios, profiling.
• Deploy ruim — a taxa de erro salta → releases canário, rollback automático quando o SLO queima.
• Réplica com estado morre — usuários perdem a sessão → mantenha as réplicas sem estado.

No playground. app é um nó de chamada (call): cada requisição chama todas as arestas de saída (em sequência por padrão, latências se somam; parallelCalls as torna paralelas, latência = máximo). Parâmetros principais (padrões entre parênteses): replicas (1), capacity por réplica (500 req/s), latencyMs (tempo de serviço mediano, 10 ms, lognormal), threads por réplica (200, o limite de concorrência da Lei de Little), queueLimit (200), autoscale com minReplicas, maxReplicas, targetUtil e warmupS (1, 20, 0,6, 60 s) e leakPerMin para testes soak. Os parâmetros das arestas (timeoutMs, retries, backoff, circuitBreaker, fallback) protegem as chamadas dele. Cenários: monolith, scale-out, cascading-failure.

Produtos reais.

Saiba mais: Computação › Serviços · Computação › Serverless e autoescala · Estimativas › Filas · Confiabilidade › Padrões · Hands-on 1 · Hands-on 2

Worker

O que é. Um processo em segundo plano que puxa tarefas de uma fila ou de um stream e as processa fora da requisição do usuário: enviar e-mails, gerar ingressos em PDF, transcodificar vídeo, chamar a API lenta de um parceiro, recalcular um feed. Workers são os consumidores do mundo assíncrono: o produtor responde na hora ("seu pedido foi recebido") e o trabalho acontece alguns segundos depois, no ritmo que os workers conseguem sustentar.

Quando usar.

• Trabalho lento, pesado ou pouco confiável pelo qual o usuário não precisa esperar (BoxOffice: confirmação por e-mail, ingresso em PDF, nota fiscal).
• Para absorver picos: a fila guarda o acúmulo enquanto os workers o drenam em ritmo constante (cenário async-queue).
• Para repetir com segurança o trabalho que falhou, com backoff e uma fila de mensagens mortas (DLQ, dead-letter queue) para as tarefas que continuam falhando.
• Tarefas em lote: conciliação noturna de pagamentos, reindexação do catálogo de busca.

Quando não usar (ou cuidado).

• Quando o usuário precisa do resultado agora (meu assento está reservado?) — isso é uma chamada síncrona.
• A entrega normalmente é pelo menos uma vez (at least once): a mesma tarefa pode rodar duas vezes → torne o worker idempotente (deduplique pelo id da tarefa/evento).
• Uma fila esconde sobrecarga: se os produtores superam os consumidores por muito tempo, o acúmulo e o atraso ponta a ponta crescem sem limite → alerte sobre o atraso do consumidor e faça autoescala dos workers pela profundidade da fila.
• A maioria das filas não garante ordem; quando a ordem importa por chave, use um log particionado (Kafka) com um consumidor por partição.

Números-chave.

Modos de falha.

• Mensagem envenenada — uma tarefa sempre derruba o worker e é reentregue para sempre → contagem máxima de recebimentos + DLQ.
• Processamento duplicado — o worker cai depois de produzir o efeito, mas antes do ack → consumidores idempotentes, tabela de deduplicação.
• Atraso crescente — consumidores mais lentos que os produtores → autoescala pela profundidade da fila (KEDA), mais partições, código mais rápido.
• Sobrecarga a jusante — 100 workers martelam um provedor com cota → limite a concorrência dos workers ao rate limit do provedor.

No playground. worker é um nó de chamada que fica atrás de um nó de mensageria: a fila guarda um acúmulo (backlog) e os workers o drenam a replicas × capacity (padrões 2 × 100 mensagens/s). Observe o acúmulo, o atraso do consumidor e a latência ponta a ponta (assíncrona) no painel de métricas; com Kafka/streams, o paralelismo é limitado por min(partitions, réplicas de workers). Parâmetros: replicas, capacity, latencyMs (50 ms), autoscale. Cenários: async-queue, video-streaming, notification-system.

Produtos reais.

Saiba mais: Computação › Trabalho assíncrono · Mensageria › Filas e pub/sub · Mensageria › Semântica · Hands-on 7

Serverless

O que é. Functions as a Service (FaaS): você envia uma função e a plataforma a executa por evento (uma requisição HTTP, uma mensagem, um upload de arquivo, um timer), escalando de zero a milhares de instâncias concorrentes e cobrando por invocação e por milissegundo de execução. Você não administra servidores, mas aceita os limites da plataforma: duração máxima, memória, cotas de concorrência e cold starts (o atraso quando uma instância nova precisa ser criada).

Quando usar.

• Cargas curtas, com picos ou imprevisíveis: miniaturas de imagem depois de um upload, webhooks do provedor de pagamentos, um relatório noturno.
• Código de cola entre serviços gerenciados (um objeto novo no armazenamento → processá-lo → escrever em uma fila).
• APIs de pouco tráfego, em que pagar por servidores ociosos dominaria o custo.

Quando não usar (ou cuidado).

• Caminhos críticos de latência que não toleram cold starts (centenas de ms a segundos), a menos que você pague por instâncias provisionadas/mínimas.
• Trabalho longo ou com estado (a duração máxima do Lambda é de 15 minutos).
• Vazão alta e constante: com carga alta e estável, contêineres ou VMs costumam ser mais baratos por requisição.
• Escalar rápido pode matar o seu banco: 1.000 funções concorrentes abrindo uma conexão cada esgotam o PostgreSQL → pooler/proxy de conexões, limites de concorrência.

Números-chave.

Modos de falha.

• Throttling — o limite de concorrência é atingido e as invocações falham (429) → concorrência reservada, fila na frente, aumento de cotas.
• Latência de cauda por cold start — p99 dominado por instâncias novas → instâncias provisionadas/mínimas, runtimes mais leves, snapshots.
• Tempestade de conexões no banco → RDS Proxy / PgBouncer, limitar a concorrência.
• Retries de invocações assíncronas causam duplicatas → handlers idempotentes.
• Custo descontrolado — um laço (a função escreve no bucket que a dispara) → proteções, orçamentos e alertas.

No playground. serverless é um nó de chamada com autoescala embutida: as requisições que precisam de uma instância nova pagam um cold start (coldStartMs, padrão 600 ms), a menos que instâncias provisioned fiquem sempre quentes, e acima do concurrencyLimit (padrão 1.000) as requisições são limitadas (429). O custo é por invocação mais GB-segundo (memGB). Compare-o com um nó app no perfil spike. Cenários: serverless-burst, video-streaming.

Produtos reais.

Saiba mais: Computação › Serverless e autoescala · Cloud-native › FinOps · Estudo de caso: streaming de vídeo

Auth Service

O que é. O serviço que responde quem é você? (autenticação) e emite credenciais que o resto do sistema consegue verificar de forma barata: normalmente OAuth 2.1 / OpenID Connect (OIDC) com access tokens de vida curta (muitas vezes JWTs, assinados para que qualquer serviço os valide localmente) e refresh tokens de vida mais longa. Ele gerencia usuários, senhas (com hash Argon2 ou bcrypt), autenticação multifator, login social e sessões. O que você pode fazer? (autorização) é verificado depois pelo gateway e pelos serviços usando as claims do token.

Quando usar.

• Sempre, em qualquer sistema com contas. No BoxOffice, comprar exige login; navegar, não.
• Como serviço separado (ou um provedor de identidade gerenciado), para que picos de login e correções de segurança não toquem os serviços de negócio.
• Centralize a validação de tokens no API gateway; os serviços ainda verificam permissões finas (este usuário pode cancelar este pedido?).

Quando não usar (ou cuidado).

• Não crie a sua própria criptografia ou armazenamento de senhas; use um provedor de identidade ou uma biblioteca comprovados.
• Não chame o serviço de autenticação a cada requisição para validar um token — verifique a assinatura do JWT localmente com as chaves públicas em cache (JWKS).
• JWTs de vida longa não são fáceis de revogar → expiração curta (minutos) + refresh tokens + uma lista de revogação para emergências.
• O login é um alvo favorito de ataques → limites de taxa, proteção contra credential stuffing, MFA.

Números-chave.

Modos de falha.

• Pane da autenticação = pane total das funções que exigem login → redundância; a validação local de tokens mantém as sessões existentes funcionando.
• Tempestade de logins em um horário marcado, amplificada pelo hash lento de senhas → autoescala, incentivar o login antes de as vendas abrirem.
• Rotação de chaves quebra a validação → publicar as novas chaves no JWKS antes de assinar com elas, cache com renovação.
• Vazamento de tokens → vidas curtas, só HTTPS, flags seguras nos cookies, PKCE para clientes públicos.

No playground. auth é um nó de chamada como app (parâmetros replicas, capacity (3.000 req/s), latencyMs (4 ms), threads, autoscale). Coloque-o atrás do gateway com ratio < 1 na aresta para modelar que só algumas requisições (logins, renovação de tokens) chegam até ele, enquanto o resto é validado localmente. Monte-o em um projeto blank ou estenda o flash-sale.

Produtos reais.

Saiba mais: Rede e segurança › Identidade · Rede e segurança › Zero trust · Computação › Serviços · Hands-on 4

Search

O que é. Um serviço de busca responde a consultas de texto ("coldplay são paulo", com erros de digitação) ordenadas por relevância, com filtros e facetas (data, cidade, preço). Ele é construído sobre um índice invertido: para cada termo, a lista de documentos que o contêm. O índice normalmente é uma cópia secundária de dados cuja fonte da verdade é o banco, mantida atualizada por eventos ou por captura de mudanças (CDC, change data capture); atualizações ficam visíveis depois de um refresh curto (quase em tempo real).

Quando usar.

• Busca textual, correspondência aproximada, ordenação por relevância, autocompletar, navegação por facetas — coisas que um LIKE '%...%' em SQL faz mal e devagar.
• No BoxOffice: buscar eventos por artista, local, cidade e data.
• Busca em logs e análise de documentos semiestruturados.
• Busca híbrida (palavras-chave + similaridade vetorial) para assistentes de IA.

Quando não usar (ou cuidado).

• Não é fonte da verdade: sem consistência forte, sem transações entre documentos. A disponibilidade de assentos precisa vir do inventory, não do índice.
• Manter o índice sincronizado é uma tarefa de projeto à parte (escritas duplas são inseguras → outbox/CDC).
• Buscas exatas por id ou filtros simples são mais baratos no banco principal.
• No Elasticsearch/OpenSearch, os shards são fixados na criação do índice; redimensionar significa reindexar.

Números-chave.

Modos de falha.

• Índice dessincronizado — um evento cancelado no banco ainda aparece → pipeline de CDC/outbox, reconciliação periódica, mostrar a disponibilidade a partir da fonte da verdade.
• Consultas caras (curingas no início, agregações enormes) saturam o cluster → limites de consulta, timeouts, cache das consultas populares.
• Shards quentes → roteamento/sharding melhores, réplicas para leitura.
• Reindexação sob carga → construir um índice novo em segundo plano e trocar um alias.

No playground. search é um nó de chamada (parâmetros replicas, capacity (800 consultas/s), latencyMs (25 ms), threads, autoscale). Coloque um cache na frente dele para os prefixos populares e veja a taxa de acerto cortar a carga. Cenário: search-autocomplete.

Produtos reais.

Saiba mais: Bancos de dados › Especializados · Mensageria › Padrões · Estudo de caso: autocompletar de busca

Scheduler

O que é. Um componente que dispara trabalho pelo tempo, não por uma requisição: "todo dia às 03:00 concilie os pagamentos", "a cada minuto libere as reservas de assento expiradas", "envie um lembrete 24 h antes de cada show". Schedulers simples executam expressões cron; os distribuídos garantem que cada tarefa rode uma vez mesmo com várias réplicas (eleição de líder ou um lock), guardam histórico, repetem falhas e lidam com muitas tarefas adiadas (uma por pedido ou por show).

Quando usar.

• Manutenção periódica: liberar reservas expiradas no inventory, limpar dados, rotacionar chaves, atualizar views materializadas.
• Temporizadores de negócio: lembretes antes de um evento, avisos de carrinho abandonado, abrir as vendas às 10:00 em ponto.
• Pipelines em lote: exportações noturnas para o data warehouse, relatórios.

Quando não usar (ou cuidado).

• Manada em horários redondos: milhares de tarefas marcadas para 00:00 disparam juntas → espalhe os horários de início (jitter).
• Rodar cron em todas as réplicas da aplicação executa a tarefa N vezes → um scheduler, um lock distribuído ou eleição de líder.
• Uma tarefa que dura mais que o seu intervalo se sobrepõe a si mesma → proíba execuções concorrentes.
• Para "faça X quando Y acontecer", um evento é melhor que consultar periodicamente.

Números-chave.

Modos de falha.

• Execução dupla — duas réplicas disparam → eleição de líder, locks com fencing tokens, tarefas idempotentes.
• Execução perdida — o scheduler estava fora do ar às 03:00 → política de recuperação, monitoração de "tarefa não rodou" (alerta dead-man's switch).
• Rajada na hora cheia sobrecarrega filas e provedores → jitter, despacho com limite de taxa por uma fila.
• Bugs de relógio e fuso horário (horário de verão, UTC vs local) → agendar em UTC, testar as transições de horário de verão.

No playground. scheduler gera a sua própria carga periódica: jobs tarefas a cada everyS segundos (padrões 1.000 a cada 60 s, todas de uma vez, a menos que spreadS as espalhe) para os seus alvos (normalmente uma fila que alimenta workers), independentemente do tráfego dos clientes. Aumente N para ver a rajada a cada disparo e como uma fila a suaviza. Cenário: notification-system.

Produtos reais.

Saiba mais: Computação › Trabalho assíncrono · Distribuídos › Consenso · Estudo de caso: sistema de notificações

Notifications

O que é. Um serviço que transforma "avise este usuário de X" em mensagens reais no canal certo — push (APNs, FCM), e-mail, SMS, no app — respeitando as preferências e os opt-outs do usuário, renderizando templates, deduplicando, limitando a taxa por usuário e repetindo quando os provedores falham. Ele fica atrás de uma fila: os produtores publicam eventos de "pedido confirmado" e o serviço de notificações os distribui pelos canais no ritmo que os provedores externos aceitam.

Quando usar.

• Sempre que várias partes do sistema precisarem falar com os usuários: order (confirmação), inventory (reserva prestes a expirar), scheduler (lembretes de show), marketing.
• Para isolar os serviços de negócio das manias dos provedores (cotas, panes, APIs diferentes).
• Para ter um lugar único para preferências, horários de silêncio, localização e auditoria ("este usuário foi avisado?").

Quando não usar (ou cuidado).

• Nunca envie notificações de forma síncrona dentro da requisição de compra; publique um evento e responda.
• Push e SMS são melhor esforço: informação importante precisa estar também no app ou no e-mail.
• Não avise duas vezes: a entrega pelo menos uma vez exige uma chave de deduplicação por (usuário, notificação).
• Respeite a lei e o consentimento do usuário (opt-in para marketing, links de descadastro).

Números-chave.

Modos de falha.

• Pane ou limitação do provedor (429) → fila + retries com backoff, um segundo provedor para canais críticos.
• Notificações duplicadas → chave de idempotência por mensagem, armazenamento de deduplicação.
• Tempestade de notificações — um bug ou um grande evento envia milhões de uma vez → limites por usuário, taxa global de envio, chave de desligamento (kill switch).
• Template quebrado estraga todas as mensagens → testes de template, implantação gradual.

No playground. notifications é um nó de chamada normalmente posto depois de uma fila: ele consome o acúmulo e chama o provedor externo email, cuja cota (quota, padrão 100 envios/s) e panes aleatórias tornam retries e DLQs necessários. Parâmetros: replicas, capacity (1.000 req/s), latencyMs (15 ms), autoscale; na aresta até o provedor, timeoutMs, retries, backoff. Cenários: notification-system, flash-sale.

Produtos reais.

Saiba mais: Computação › Integrações · Mensageria › Filas e pub/sub · Estudo de caso: sistema de notificações · Hands-on 7

Analytics

O que é. O pipeline que transforma eventos brutos (visualizações de página, buscas, reservas, compras, cliques) em números que as pessoas conseguem usar: dashboards ("ingressos vendidos por minuto"), funis (quantos que reservaram um assento de fato pagaram?), sinais de fraude, recomendações. Os eventos são coletados de forma assíncrona, normalmente por um stream, e depois processados em tempo real (processamento de streams) e/ou em lote em um data warehouse. É o lado de leitura do negócio, mantido longe dos bancos transacionais.

Quando usar.

• Métricas de produto e de negócio, testes A/B, funis, dashboards de vendas para os organizadores de eventos.
• Contadores em tempo real durante a venda relâmpago (vendidos, reservados, tamanho da sala de espera).
• Analytics de cliques de um encurtador de URL, contagem de visualizações de uma plataforma de vídeo.

Quando não usar (ou cuidado).

• Não rode consultas analíticas no banco OLTP de produção: um GROUP BY grande pode deixar as compras lentas → replique para um warehouse (CDC/ELT).
• Não faça a requisição do usuário esperar pela escrita de analytics: dispare e esqueça em um stream.
• Números de analytics costumam ser aproximados e um pouco atrasados; não os use para garantir invariantes (contagem de assentos).
• Dados pessoais: anonimize/agregue e respeite as regras de retenção (LGPD/GDPR).

Números-chave.

Modos de falha.

• Acúmulo no analytics atrasa os dashboards → é assíncrono; escale os consumidores, aceite o atraso, nunca bloqueie o caminho de compra.
• Contagem dupla com entrega pelo menos uma vez → ids de evento e deduplicação, ou tolerar pequenos erros.
• Deriva de schema — um produtor muda o formato do evento e quebra os pipelines → schema registry, eventos versionados.
• Partições quentes — um evento enorme inunda uma partição → particione por uma chave bem distribuída.

No playground. analytics é um nó de chamada normalmente ligado de forma assíncrona (por um nó stream, kafka ou pubsub), fora do caminho da requisição: observe o atraso do consumidor crescer durante picos sem afetar a latência do usuário. Parâmetros: replicas, capacity (2.000 eventos/s), latencyMs (20 ms). Cenários: event-fanout, url-shortener.

Produtos reais.

Saiba mais: Bancos de dados › Especializados · Mensageria › Kafka · Estudo de caso: encurtador de URL · Estudo de caso: news feed