Cliente

Todo projeto começa e termina em um cliente: o programa que envia a primeira requisição e espera o último byte da resposta. No playground, os nós de cliente são onde o tráfego nasce — o perfil de carga (smoke, load, stress, spike, soak, breakpoint, chaos) decide quantas requisições por segundo saem deles. No BoxOffice, os clientes são os navegadores dos fãs e o aplicativo móvel: em um dia normal eles navegam pelo catálogo; às 10:00 de um dia de venda relâmpago, 2 M deles apertam "Comprar" no mesmo minuto.

Pensar no cliente não é formalidade. Onde o cliente está (latência até a sua borda), o que ele consegue fazer (cache, retry, manter uma conexão aberta) e como ele se comporta diante de falhas (tenta de novo na hora? o usuário martela o F5?) molda todo o projeto que está atrás dele.

flowchart LR
    B[Client<br/>navegador / SDK] --> DNS
    M[Mobile<br/>iOS / Android] --> DNS
    DNS --> CDN
    CDN --> LB[Load Balancer]
    LB --> APP[App Server]

Client

O que é. O cliente genérico: um navegador web, uma ferramenta de linha de comando, o backend de outra empresa ou uma ferramenta de teste de carga como o k6. Ele abre conexões (TCP + TLS, ou QUIC), envia requisições HTTP e espera as respostas. Está fora do seu controle — você não consegue corrigi-lo, não pode confiar nele e ele pode estar do outro lado do planeta.

Quando usar.

• Como ponto de entrada de todo projeto no playground: o nó de cliente é a carga de trabalho (requisições por segundo, mistura leitura/escrita, popularidade das chaves).
• Para raciocinar sobre a latência percebida pelo usuário: o número que importa é medido no cliente, incluindo DNS, handshakes TLS e as idas e voltas até a sua borda.
• Para decidir o que pode ser empurrado para o cliente: arquivos estáticos em cache no navegador (Cache-Control), renderização no cliente, chaves de idempotência geradas pelo cliente, backoff exponencial no SDK.

Quando não usar (ou cuidado).

• Nunca coloque no cliente regras de negócio ou segredos que precisem ser confiáveis: preço, disponibilidade de assentos e autorização devem ser validados no servidor.
• Não presuma que os clientes se comportam: um botão "Comprar" sem debounce, um laço de retry sem backoff ou um robô raspando o site podem multiplicar a sua carga.
• Não dimensione o sistema pelo cliente médio; dimensione pelo pico (venda relâmpago) e pela pior rede (3G móvel dentro de um estádio).

Números-chave.

Modos de falha.

• Tempestade de retries — clientes (ou usuários apertando F5) tentam de novo imediatamente após erros e multiplicam a carga durante uma pane → backoff exponencial com jitter no SDK, cabeçalho Retry-After, sala de espera.
• Manada no horário marcado — todos os clientes acordam às 10:00:00 → início com atraso aleatório, admissão por fila (sala de espera), caches pré-aquecidos.
• Envios duplicados — clique duplo ou timeout + retry criam dois pedidos → chaves de idempotência geradas pelo cliente e deduplicadas no servidor.
• Cache velho no cliente — o navegador mantém um bundle JavaScript antigo → nomes de arquivo com hash do conteúdo, TTL curto no HTML.
• Clientes maliciosos — robôs, credential stuffing, cambistas → WAF, rate limiting, CAPTCHA/prova de trabalho, autenticação.

No playground. O nó client é uma fonte de tráfego, não um servidor: ele não tem capacidade. As chegadas a cada tick seguem um processo de Poisson cuja taxa λ(t) vem do perfil de carga e do RPS alvo da barra de ferramentas. Seus parâmetros principais são readRatio (fração de leituras; o padrão da barra de ferramentas é 0,9), zipfS (assimetria da popularidade das chaves, padrão 0,8, usada por caches e partições para criar chaves quentes), botShare (tráfego extra de robôs, padrão 0) e timeoutMs (a paciência do usuário, padrão 30 s). Os percentis de latência e a taxa de erro do painel de métricas são medidos do ponto de vista do cliente. Todo cenário começa aqui; bons primeiros cenários: monolith, scale-out, flash-sale.

Produtos reais.

Saiba mais: Intro › Requisitos · Estimativas › Números · Borda › Protocolos · Performance › Testes de carga · Hands-on 2

Mobile

O que é. Um aplicativo nativo (iOS, Android) ou um app web móvel em um celular. É um cliente com restrições extras: a rede muda o tempo todo (Wi-Fi → 4G → sem sinal no túnel do estádio), a bateria é preciosa, a versão do app nas mãos dos usuários pode ter meses e o sistema operacional pode matá-lo a qualquer momento. Em troca, ele pode guardar dados localmente, funcionar offline e receber notificações push.

Quando usar.

• Quando o produto precisa de notificações push (BoxOffice: "seus ingressos estão prontos", "os portões abrem em 1 hora").
• Quando a experiência precisa sobreviver a redes ruins: ingressos guardados no aparelho e exibidos offline na catraca (QR code).
• Para modelar uma segunda fonte de tráfego com outra mistura: clientes móveis costumam fazer mais requisições, menores, e reconectar com frequência.

Quando não usar (ou cuidado).

• Versões antigas do app vivem por muito tempo: nunca quebre uma API usada por um app já publicado; versione a API e mantenha compatibilidade retroativa.
• Não converse demais com o backend: cada requisição em rede móvel custa latência e bateria → agrupe chamadas, use um BFF (Backend for Frontend) que devolve exatamente o que uma tela precisa.
• Não embarque segredos no binário do app (chaves de API podem ser extraídas); use OAuth 2.1 com PKCE (Proof Key for Code Exchange).

Números-chave.

Modos de falha.

• Conexão cai no meio da requisição — o app não sabe se a compra deu certo → chave de idempotência + um endpoint de status para consultar ("o pedido X foi concluído?").
• Tempestade de reconexões — depois de uma pane de rede ou do backend, milhões de apps reconectam ao mesmo tempo → atraso aleatório de reconexão com backoff exponencial e jitter.
• Mudança incompatível na API — uma versão antiga do app quebra → versionamento de API, testes de contrato, versão mínima suportada.
• Relógio do aparelho errado — o relógio do celular está errado e os tokens parecem expirados → valide o tempo no servidor, use timestamps do servidor.
• Falha ou limitação do provedor de push → trate push como melhor esforço e mantenha a informação disponível no app e por e-mail.

No playground. mobile é uma fonte de tráfego como client, com os mesmos parâmetros (readRatio, zipfS, botShare), mas um timeoutMs padrão menor (15 s em vez de 30 s), guiada pelo mesmo perfil de carga. Use-o ao lado de um nó client para modelar duas populações com misturas diferentes de leitura/escrita ou para encaminhá-las por caminhos diferentes (por exemplo, o mobile passando por um API Gateway que faz papel de BFF). Cenários: chat, ride-sharing, notification-system.

Produtos reais.

Saiba mais: Borda › Protocolos · Computação › Estilos de API · Rede e segurança › Identidade · Estudo de caso: chat · Estudo de caso: sistema de notificações