Forem: Milton Camara

Redis além do tutorial. Com os problemas que ninguém te conta

Milton Camara — Tue, 12 May 2026 14:16:15 +0000

Seu banco de dados é rápido. As queries estão otimizadas. Os índices estão no lugar. E mesmo assim, sob carga real, o sistema continua lento.

O problema muitas vezes não é o banco em si. É que você está pedindo para ele responder as mesmas perguntas, repetidamente, milhares de vezes por segundo.

É aqui que o Redis começa a importar.

Mas ao contrário do que muitos tutoriais sugerem, o Redis não é mágica. É uma ferramenta com trade-offs muito específicos — e usá-la errado pode criar problemas piores do que os que você tentou resolver.

Como o Redis Funciona Por Dentro

Redis armazena tudo em RAM como pares chave–valor, mas os valores não se limitam a strings simples. Ele suporta um conjunto rico de estruturas de dados:

Estrutura	Casos de uso típicos
Strings	Contadores, flags, resultados em cache
Hashes	Perfis de usuário, dados de sessão
Lists	Filas, feeds de atividade recente
Sets	Tags, relacionamentos únicos
Sorted Sets	Leaderboards, ranking com score
Streams	Log de eventos com consumer groups

Cada estrutura vem com comandos otimizados que operam diretamente nos dados. Isso é a chave: em vez de buscar tudo e processar na sua aplicação, você delega a operação ao Redis.

A diferença entre ZRANGE leaderboard 0 9 REV WITHSCORES e buscar 10.000 linhas e ordenar no código é drástica em escala.

Por que RAM Não é o Único Motivo

A maioria das pessoas assume que Redis é rápido "porque usa RAM". Isso é verdade, mas incompleto.

O ganho real está em evitar round-trips desnecessários ao banco. Mesmo em redes locais de baixa latência, cada chamada TCP ao banco custa entre 0.5ms e 5ms. Com 500 usuários simultâneos fazendo 10 requests por segundo cada, você está fazendo 5.000 chamadas/segundo ao banco, sendo que boa parte delas responde a mesma pergunta.

Redis elimina essa camada de comunicação para os dados mais acessados. O hit em cache retorna em microssegundos não só porque está em RAM, mas porque está na mesma máquina, sem handshake TCP, sem parser de query, sem plano de execução.

O Event Loop Single-Threaded

Redis usa um event loop de thread única, um comando executa de cada vez.

Isso parece limitante. Na prática, é uma escolha deliberada e que funciona bem para workloads típicos: sem locks, sem contenção, operações atomicamente previsíveis. Em benchmarks, o Redis processa centenas de milhares de operações por segundo em hardware comum porque cada operação é pequena, previsível e não bloqueia outras.

O modelo escala bem enquanto os comandos são simples e rápidos, que é o caso da esmagadora maioria dos usos reais de Redis.

Onde isso vira problema: A partir do Redis 6.0, o I/O de rede passou a ser multi-threaded, mas a execução dos comandos continua single-threaded. Comandos lentos como KEYS *, SORT sem LIMIT, ou LRANGE em listas muito grandes bloqueiam todo o servidor enquanto executam. Um único comando mal escrito pode degradar o sistema inteiro. É por isso que KEYS * em produção é considerado um erro grave.

Persistência: Você Escolhe o Risco

Redis é in-memory, mas pode persistir dados de duas formas:

RDB (Redis Database): Snapshots periódicos. Mais rápido, mas você pode perder as escritas desde o último snapshot.
AOF (Append-Only File): Registra cada operação de escrita. Mais durável, mas gera arquivos grandes e pode impactar latência dependendo do fsync configurado (always, everysec, no).

Você pode usar ambos simultaneamente. A configuração padrão (appendfsync everysec) aceita perder até 1 segundo de dados em caso de crash, aceitável para cache, problemático para dados financeiros.

Onde o Redis Realmente Brilha (Com Código)

1. Caching - O Padrão Cache-Aside

O caso de uso mais comum. A aplicação verifica o Redis primeiro; em um hit, os dados retornam em microssegundos; em um miss, a aplicação consulta o banco e popula o Redis.

Em .NET, a abstração mais portável é IDistributedCache:

public class ProductService
{
    private readonly IDistributedCache _cache;
    private readonly IProductRepository _repository;
    private static readonly TimeSpan CacheDuration = TimeSpan.FromMinutes(10);

    public ProductService(IDistributedCache cache, IProductRepository repository)
    {
        _cache = cache;
        _repository = repository;
    }

    public async Task<Product?> GetByIdAsync(int id)
    {
        var cacheKey = $"product:{id}";

        var cached = await _cache.GetStringAsync(cacheKey);
        if (cached is not null)
            return JsonSerializer.Deserialize<Product>(cached);

        var product = await _repository.GetByIdAsync(id);
        if (product is null) return null;

        await _cache.SetStringAsync(
            cacheKey,
            JsonSerializer.Serialize(product),
            new DistributedCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = CacheDuration
            });

        return product;
    }
}

Configuração no Program.cs:

builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = builder.Configuration.GetConnectionString("Redis");
    options.InstanceName = "myapp:";
});

Quando isso funciona bem: Para dados lidos muito mais frequentemente do que mudam. A chave é ter um TTL razoável e aceitar que usuários diferentes podem ver versões ligeiramente diferentes do dado durante a janela de cache.

2. Rate Limiting — Atomicidade é Tudo

Redis torna rate limiting simples através de operações atômicas. Com StackExchange.Redis:

public class RedisRateLimiter
{
    private readonly IDatabase _db;

    public RedisRateLimiter(IConnectionMultiplexer redis)
    {
        _db = redis.GetDatabase();
    }

    public async Task<bool> IsAllowedAsync(string userId, int maxRequests, TimeSpan window)
    {
        var key = $"rate_limit:{userId}:{DateTimeOffset.UtcNow.ToUnixTimeSeconds() / (long)window.TotalSeconds}";

        var current = await _db.StringIncrementAsync(key);

        if (current == 1)
            await _db.KeyExpireAsync(key, window);

        return current <= maxRequests;
    }
}

Este padrão usa uma janela fixa (fixed window). É simples, mas tem um edge case: um usuário pode fazer o dobro de requisições na virada da janela. Para uso mais preciso, o padrão sliding window usa Sorted Sets, cada requisição é inserida com timestamp como score, e você remove as entradas fora da janela antes de contar.

3. Session Storage

Sessions precisam de leituras e escritas rápidas em cada requisição. Redis se encaixa porque:

Latência baixa sem delay por request
TTL nativo, sessões expiram automaticamente sem cleanup jobs
Alta throughput para bases de usuários grandes

No ASP.NET Core, a configuração é direta:

builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = "localhost:6379";
});

builder.Services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromMinutes(30);
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
});

4. Pub/Sub vs. Streams — Saiba a Diferença

Redis tem Pub/Sub built-in:

// Publisher
var sub = multiplexer.GetSubscriber();
await sub.PublishAsync("order:created", JsonSerializer.Serialize(order));

// Subscriber
await sub.SubscribeAsync("order:created", (channel, message) =>
{
    var order = JsonSerializer.Deserialize<Order>(message!);
    // processar pedido
});

Pub/Sub é simples e eficiente, mas tem uma limitação fundamental: mensagens são fire-and-forget. Se nenhum subscriber estiver ouvindo no momento do publish, a mensagem é perdida para sempre. Não há histórico, não há replay, não há garantia de entrega.

Para workloads onde isso importa, Redis Streams é a alternativa correta. A diferença conceitual é significativa:

	Pub/Sub	Streams
Persistência	Nenhuma — mensagem some após entrega	Persistida no log até você deletar
Consumer groups	Não — todos recebem tudo	Sim — múltiplos consumers dividem as mensagens
Replay	Impossível	Sim — leitura por offset ou timestamp
Pending entries	Não existe	Sim — mensagens entregues mas não confirmadas ficam no PEL
Caso de uso	Notificações em tempo real, broadcast	Pipelines de eventos, filas duráveis

Com Streams, um consumer group garante que cada mensagem seja processada por exatamente um consumer do grupo. Se o consumer falha antes de confirmar (XACK), a mensagem fica no Pending Entries List (PEL) e pode ser reclamada e reprocessada. Isso não existe no Pub/Sub.

Resumindo: use Pub/Sub para broadcast em tempo real onde perder mensagens é tolerável. Use Streams quando você precisa de garantias de entrega, múltiplos consumers independentes ou auditoria de eventos.

Benefícios vs. Trade-offs

	Benefício	Trade-off
Velocidade	Microssegundos de latência, sem round-trips ao banco	RAM é cara por GB; inviável para datasets grandes e frios
Simplicidade	API rica e intuitiva	Operações relacionais e agregações complexas não existem
Flexibilidade	Múltiplos data structures otimizados	Modelagem exige pensar diferente de um banco relacional
Durabilidade	Configurável (RDB + AOF)	Por padrão, risco de perda de dados em crash
Operação	Cloud-managed disponível	Cluster mode tem complexidade; resharding não é trivial

As Armadilhas Que Aparecem em Produção

Esta é a parte que a maioria dos artigos ignora. Redis em produção tem problemas específicos que se manifestam sob carga real.

Cache Stampede (Thundering Herd)

Imagine 10.000 usuários acessando simultaneamente um dado cujo cache acabou de expirar. Todos consultam o banco ao mesmo tempo. O banco sofre um spike de carga. Paradoxalmente, o cache que deveria proteger o banco o derruba no exato momento em que expira.

Como mitigar:

1. Probabilistic Early Expiration (PER): Antes do TTL expirar, alguns processos já começam a renovar o cache de forma probabilística:

public async Task<T?> GetWithEarlyRenewalAsync<T>(
    string key,
    Func<Task<T>> factory,
    TimeSpan ttl,
    double beta = 1.0)
{
    var db = _redis.GetDatabase();
    var raw = await db.StringGetWithExpiryAsync(key);

    if (raw.Value.HasValue)
    {
        var remaining = raw.Expiry ?? TimeSpan.Zero;
        var recomputeTime = EstimatedRecomputeTime; // medir em produção

        // Decide probabilisticamente se renova antes de expirar
        var shouldRenew = -recomputeTime.TotalSeconds * beta * Math.Log(Random.Shared.NextDouble()) >= remaining.TotalSeconds;

        if (!shouldRenew)
            return JsonSerializer.Deserialize<T>(raw.Value!);
    }

    var result = await factory();
    await db.StringSetAsync(key, JsonSerializer.Serialize(result), ttl);
    return result;
}

2. Mutex/Lock no miss com ownership: Apenas um processo refaz a query; os outros aguardam ou retornam o dado stale temporariamente. Mas atenção ao bug clássico desta abordagem: se o processo que adquiriu o lock demorar mais do que o TTL do lock para terminar, o lock expira, outro processo o adquire, e o processo original — ao finalizar — deleta o lock do processo errado, criando uma race condition silenciosa.

A solução é usar um token de ownership: só quem criou o lock pode deletá-lo.

var lockKey = $"lock:{cacheKey}";
var lockToken = Guid.NewGuid().ToString(); // token único por processo

var lockAcquired = await _db.StringSetAsync(
    lockKey, lockToken, TimeSpan.FromSeconds(5), When.NotExists);

if (lockAcquired)
{
    try
    {
        var fresh = await _repository.GetByIdAsync(id);
        await _cache.SetStringAsync(cacheKey, JsonSerializer.Serialize(fresh), options);
        return fresh;
    }
    finally
    {
        // Deleta APENAS se o token ainda é o nosso — operação atômica via Lua
        const string releaseLua = @"
            if redis.call('get', KEYS[1]) == ARGV[1] then
                return redis.call('del', KEYS[1])
            else
                return 0
            end";
        await _db.ScriptEvaluateAsync(releaseLua, [(RedisKey)lockKey], [lockToken]);
    }
}
else
{
    await Task.Delay(50);
    var retry = await _cache.GetStringAsync(cacheKey);
    return retry is not null ? JsonSerializer.Deserialize<Product>(retry) : null;
}

Para distributed locking em ambientes com múltiplas instâncias Redis (cluster ou sentinel), o algoritmo RedLock oferece garantias mais fortes, adquirindo o lock em N instâncias independentes. A biblioteca RedLock.net implementa isso para .NET. Para a maioria dos casos com uma instância Redis, o padrão acima com token é suficiente.

Key Eviction: O Redis Descarta Dados Silenciosamente

Quando a memória do Redis está cheia e maxmemory está configurado, o Redis precisa remover chaves. A política padrão (noeviction) retorna erros de escrita — o que derruba a aplicação silenciosamente se não for tratado.

As políticas mais comuns:

Política	Comportamento
`noeviction`	Erros nas escritas quando memória cheia. Seguro para filas.
`allkeys-lru`	Remove as chaves menos recentemente usadas. Boa para cache puro.
`volatile-lru`	LRU apenas em chaves com TTL definido.
`allkeys-random`	Remove aleatoriamente. Raramente é o que você quer.
`volatile-ttl`	Remove as chaves com TTL mais curto primeiro.

Erro comum: usar Redis para cache e para dados persistentes (sessões, filas) na mesma instância sem separar políticas de eviction. Quando a memória enche, o Redis pode descartar uma sessão ativa ou uma mensagem de fila. Use instâncias separadas ou, no mínimo, chaves com TTL apenas no que pode ser descartado.

Hot Keys em Cluster Mode

Em uma instância Redis única, toda a carga vai para o mesmo processo — e ele aguenta bem. Em cluster mode, as chaves são distribuídas entre shards por hash slot. O problema: se uma chave específica é acessada muito mais do que as outras (uma página inicial, um produto em promoção, uma configuração global), ela concentra carga em um único shard enquanto os outros ficam ociosos.

Isso anula o benefício de escala horizontal do cluster.

Como detectar: o comando redis-cli --hotkeys (disponível com maxmemory-policy configurada) ou monitoramento via MONITOR em ambiente de staging.

Como mitigar:

Key sharding local: criar múltiplas chaves com sufixos (config:app:1, config:app:2, ...) e distribuir as leituras entre elas.
Client-side caching: Redis 6.0 introduziu client-side caching via o protocolo CLIENT TRACKING, permitindo que o cliente mantenha uma cópia local e invalide apenas quando o servidor notifica mudança — eliminando o round-trip para hot keys.
Cache em memória local: para dados imutáveis ou de baixíssima variação, um IMemoryCache na aplicação serve como primeira camada antes do Redis.

Memory Fragmentation

Redis aloca e libera memória constantemente. Com o tempo, a fragmentação cresce: o processo ocupa mais RAM do que os dados realmente precisam.

O indicador é o mem_fragmentation_ratio no INFO memory. Valores acima de 1.5 indicam fragmentação significativa. Acima de 2.0, você provavelmente precisa de um restart controlado ou de habilitar activedefrag (disponível desde Redis 4.0):

activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10

O Problema do KEYS * em Produção

KEYS * bloqueia o event loop single-threaded enquanto escaneia todo o keyspace. Em instâncias com milhões de chaves, isso pode causar segundos de indisponibilidade.

Nunca use KEYS * em produção. Use SCAN com cursor:

var cursor = 0L;
var pattern = "product:*";

do
{
    var result = await _db.ExecuteAsync("SCAN", cursor.ToString(), "MATCH", pattern, "COUNT", "100");
    var array = (RedisResult[])result!;
    cursor = (long)array[0];
    var keys = (RedisResult[])array[1];

    foreach (var key in keys)
        Console.WriteLine(key);

} while (cursor != 0);

SCAN não garante ausência de duplicatas, mas não bloqueia o servidor — e é iterativo, o que permite processar keyspaces enormes sem travar nada.

O que Monitorar em Produção

Redis falha de formas silenciosas: evicta dados sem avisar, fragmenta memória gradualmente, acumula latência em comandos específicos. Sem observabilidade, você descobre o problema quando o usuário reclama.

As métricas essenciais do INFO para monitorar:

Métrica	O que indica
`evicted_keys`	Chaves removidas por pressão de memória. Zero é o ideal; qualquer valor crescente é alerta.
`used_memory_rss` vs `used_memory`	A diferença é a fragmentação. Se `rss` for muito maior que `used_memory`, você tem fragmentação.
`instantaneous_ops_per_sec`	Throughput atual. Útil para correlacionar com picos de latência.
`latency` (via `LATENCY HISTORY`)	Latência por evento. Detecta comandos lentos específicos.
`connected_clients`	Pico de conexões pode indicar connection pool mal configurado.
`keyspace_hits` vs `keyspace_misses`	A taxa de hit é o indicador mais direto de eficiência do cache.

Em ambientes cloud (ElastiCache, Azure Cache for Redis), essas métricas são exportadas para CloudWatch/Azure Monitor nativamente. Em ambientes self-hosted, ferramentas como Redis Exporter + Prometheus + Grafana são o padrão de mercado.

Quando Não Usar Redis

Redis não é a ferramenta certa quando:

Dataset grande e frio: RAM custa muito por GB. Use um banco em disco e faça cache apenas do subconjunto quente.
Queries relacionais e agregações complexas: "Todos os usuários da Região A que compraram o Produto B nos últimos 30 dias" exige um banco relacional com suporte a joins e índices compostos. Redis não é otimizado para esse tipo de acesso, ele recupera por chave, não por predicado sobre os dados.
Durabilidade forte: Se perder segundos de escrita é inaceitável (transações financeiras, registros médicos), o modelo de persistência do Redis exige configuração cuidadosa, e um banco ACID-compliant é a opção mais segura.
Workload stateless e simples: Para sistemas sem cache, sem sessões e sem mensageria, adicionar Redis introduz complexidade operacional sem benefício proporcional.

Redis no Stack Real

Em arquiteturas de microsserviços, o Redis assume um segundo papel como datastore compartilhado rápido: um session store central que todos os frontends consultam, um rate limiter que todos os API gateways respeitam, ou um message broker leve que conecta serviços sem o overhead de Kafka ou RabbitMQ.

Provedores cloud oferecem Redis gerenciado (AWS ElastiCache, Azure Cache for Redis, Google Cloud Memorystore) que cuidam de provisionamento, scaling e failover. Isso facilita inserir Redis numa stack existente sem gerenciar infraestrutura diretamente.

Uma alternativa que ganhou tração recentemente é o Garnet, lançado pela Microsoft em 2024 como projeto open source. É compatível com o protocolo RESP do Redis, escrito em C#, e apresenta throughput superior em alguns benchmarks específicos de .NET. Ainda é jovem e não tem o ecossistema do Redis, mas vale acompanhar se você roda .NET.

Conclusão

Redis é um multiplicador de performance, não um substituto de banco de dados.

Ele não tenta resolver tudo. Resolve um conjunto estreito de problemas com precisão: caching, sessões, rate limiting, mensageria leve.

E é exatamente por isso que está em todo lugar.

Mas há uma armadilha real: Redis é fácil de adicionar e difícil de operar bem. Um cache sem política de eviction bem definida vira um ponto cego. Um Pub/Sub sem tratamento de mensagens perdidas vira um bug silencioso. Um distributed lock sem token de ownership vira uma race condition esperando para acontecer. Um keyspace mal modelado vira um problema de memória que aparece às 2h da manhã.

Usado corretamente, Redis transforma caminhos lentos em rápidos e sistemas frágeis em responsivos.

Usado sem cuidado, vira uma abstração cara e com vazamentos.

A diferença está em entender não só o que ele faz bem, mas onde ele mente para você.

Gostou? Deixa um comentário com o padrão que você usa Redis no seu stack. E se você já teve um cache stampede em produção, conta como resolveu, as histórias de guerra são sempre as mais úteis.

Pare de usar Logs como MULETA. Voce está fazendo ERRADO!!!

Milton Camara — Mon, 11 May 2026 17:27:51 +0000

Se você já abriu um arquivo de log de 2GB no meio da madrugada tentando descobrir por que o pagamento do cliente falhou, esse post é pra você. E não, a culpa não é da ferramenta. A culpa é sua.

A real é dura: a maioria dos devs trata log como se fosse Console.WriteLine com esteroides. Espalha LogInformation em cada método, acha que está "instrumentando" a aplicação, e quando o sistema quebra em produção fica horas "grepando" arquivo atrás de pista.

Logs não foram feitos pra explicar fluxos. Eles servem pra registrar eventos pontuais. Quem te entrega o fluxo completo de uma operação são os traces. E se você ainda não sabe a diferença, esse é o problema que você precisa resolver hoje.

O pecado capital: log como narrador de novela

Olha se você nunca escreveu algo parecido com isso:

logger.LogInformation("Entrou no método ProcessarPagamento");
logger.LogInformation("Validando dados do cliente {ClienteId}", clienteId);
logger.LogInformation("Chamando API de Pagamento com valor {Valor}", valor);
logger.LogInformation("Pagamento retornou sucesso");
logger.LogInformation("Saiu do método ProcessarPagamento");

Parece responsável. Parece "boa prática". Não é.

Esse código tem 4 problemas graves que ninguém te conta:

1. Zero correlação entre as linhas

Em produção, com 500 requests por segundo, essas 5 linhas vão estar embaralhadas com outras 50.000 de outros usuários. Boa sorte tentando montar a sequência de um pedido específico sem um TraceId.

2. Você está pagando caro por lixo

Datadog, New Relic, CloudWatch, Splunk: todos cobram por volume ingerido. Cada LogInformation("Entrou no método X") é dinheiro real saindo da sua conta. Já vi empresa gastar R$ 80k/mês em log que ninguém nunca leu.

3. PII e vazamento de dados (LGPD chegou em todo mundo)

Quando o dev coloca logger.LogInformation("Request: {@Request}", request) achando que está sendo esperto, ele acabou de logar CPF, cartão, token JWT e senha em texto puro. Auditoria vai te encontrar. A LGPD também.

4. Logs não contam história, contam fofoca

Você sabe que algo aconteceu, mas não sabe quando, quanto tempo demorou, o que veio antes nem o que veio depois. É como tentar entender um filme só pelas legendas, fora de ordem.

A virada de chave: traces

Trace é uma árvore. Cada operação (uma chamada HTTP, um query no banco, uma publicação no Kafka) é um span, e os spans se conectam formando o fluxo completo de uma requisição, mesmo quando ela atravessa 8 microsserviços diferentes.

Com trace você responde perguntas que log nunca vai conseguir responder:

"Por que esse pedido demorou 4 segundos?" → você vê exatamente qual span travou.
"O bug está no meu serviço ou no fornecedor?" → o trace mostra a cadeia inteira.
"Quantos % das requests estão lentas por causa do banco?" → métricas derivadas do span do EF Core.

E o melhor: você instrumenta uma vez, com OpenTelemetry, e exporta pra qualquer backend (Jaeger, Tempo, Datadog, Honeycomb, Azure Monitor). Sem vendor lock-in.

Hands-on: o mesmo cenário, agora bem feito (.NET 8 + OpenTelemetry)

Setup mínimo no `Program.cs`

using OpenTelemetry.Resources;
using OpenTelemetry.Trace;

builder.Services.AddOpenTelemetry()
    .ConfigureResource(r => r.AddService("MinhaApp.Pagamento"))
    .WithTracing(tracing => tracing
        .AddSource("MinhaApp.Pagamento")
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddEntityFrameworkCoreInstrumentation()
        .AddOtlpExporter()); // exporta pro coletor que você quiser

Pronto. Toda chamada HTTP de entrada, toda chamada HTTP de saída e toda query no EF Core já estão sendo rastreadas automaticamente. Você nem precisa escrever código pra isso.

Instrumentação manual onde importa

using System.Diagnostics;

public static class Telemetry
{
    public static readonly ActivitySource Source = new("MinhaApp.Pagamento");
}

public class PagamentoService
{
    private readonly HttpClient _http;
    private readonly ILogger<PagamentoService> _logger;

    public PagamentoService(HttpClient http, ILogger<PagamentoService> logger)
    {
        _http = http;
        _logger = logger;
    }

    public async Task<bool> ProcessarAsync(Guid pedidoId, int clienteId, decimal valor)
    {
        using var activity = Telemetry.Source.StartActivity(
            "processar-pagamento", 
            ActivityKind.Internal);

        // tags = metadados consultáveis no backend de observabilidade
        activity?.SetTag("pedido.id", pedidoId);
        activity?.SetTag("cliente.id", clienteId);
        activity?.SetTag("valor.total", valor);
        activity?.SetTag("moeda", "BRL");

        try
        {
            activity?.AddEvent(new ActivityEvent("validando-cliente"));
            await ValidarClienteAsync(clienteId);

            activity?.AddEvent(new ActivityEvent(
                "chamando-gateway",
                tags: new ActivityTagsCollection 
                { 
                    { "gateway", "Stripe" },
                    { "endpoint", "POST /v1/charges" }
                }));

            var response = await _http.PostAsJsonAsync("/v1/charges", new { valor });

            activity?.SetTag("http.status_code", (int)response.StatusCode);
            activity?.SetTag("response.size", response.Content.Headers.ContentLength);

            if (!response.IsSuccessStatusCode)
            {
                activity?.SetStatus(ActivityStatusCode.Error, "Gateway recusou pagamento");
                // log SÓ aqui, no erro, e SEM payload sensível
                _logger.LogWarning("Pagamento recusado para pedido {PedidoId}", pedidoId);
                return false;
            }

            activity?.SetStatus(ActivityStatusCode.Ok);
            return true;
        }
        catch (Exception ex)
        {
            activity?.RecordException(ex);
            activity?.SetStatus(ActivityStatusCode.Error, ex.Message);
            throw; // deixa o ASP.NET Core lidar
        }
    }
}

O que esse código faz que o anterior não fazia

Antes (logs)	Depois (traces)
5 linhas soltas no arquivo	1 span estruturado com início, fim e duração
Nenhuma correlação entre serviços	`TraceId` propaga automaticamente via HTTP headers
Busca textual com `grep`	Query estruturada por `pedido.id`, `cliente.id`, etc.
Sem noção de tempo	Latência precisa de cada etapa, em microssegundos
Logger genérico vazando PII	Tags controladas, sem campos sensíveis
Custo proporcional ao volume bruto	Custo proporcional a operações + sampling configurável

"E os logs, jogo fora?"

Não. Logs continuam sendo úteis. O que muda é quando você os usa:

✅ Use log pra: eventos de negócio importantes ("Pedido X cancelado pelo cliente"), erros inesperados, auditoria de ações sensíveis.
❌ Não use log pra: rastrear fluxo, medir performance, debugar requisição específica, "marcar que passou aqui".

A regra que eu sigo: se a informação faz parte da história de uma requisição, é trace. Se é um fato isolado que importa fora do contexto da requisição, é log.

E quando você precisar dos dois juntos? Correlacione pelo TraceId:

_logger.LogWarning(
    "Pedido {PedidoId} cancelado. TraceId: {TraceId}",
    pedidoId,
    Activity.Current?.TraceId);

Agora, do dashboard de logs, você clica no TraceId e cai direto no trace. Fim do grep eterno.

A pirâmide da observabilidade (decora isso)

        🔺 Logs        ← eventos pontuais, raros, com contexto
       🔺🔺 Métricas    ← agregações, dashboards, alertas
      🔺🔺🔺 Traces      ← a base de tudo, o fluxo das requests

Quem começa pela base debuga em segundos. Quem começa pelo topo debuga em horas.

Conclusão sem rodeios

Se você ainda está enchendo seu código de LogInformation achando que está fazendo observabilidade, você está uma década atrás do estado da arte. Trace não é luxo de Big Tech, é o mínimo pra qualquer aplicação séria em 2026.

Instala o OpenTelemetry hoje. Roda um Jaeger ou Tempo local. Vê seu sistema do jeito que ele realmente é: uma árvore de operações com latências, erros e dependências. Você nunca mais vai voltar pro tail -f.

E aí, vai continuar caçando agulha no palheiro ou vai aprender a usar a ferramenta certa?

💬 Se esse post fez sentido, deixa um comentário com o pior cenário de "debug por log" que você já viveu.

🔍 Como tornei milhões de conversas históricas "invisíveis" buscáveis em tempo real

Milton Camara — Mon, 11 May 2026 14:40:00 +0000

O problema

Trabalhei recentemente em uma solução para um cenário que muita gente que
mexe com sistemas em escala já enfrentou: um sistema gera diariamente
arquivos JSON que vão para um storage ou qualquer outro banco como histórico, seguindo um padrão de nomenclatura previsível. Com o tempo, esses arquivos se acumulam aos milhões.

A dor apareceu quando surgiu a necessidade de consultar esse histórico.

Três problemas surgiram ao mesmo tempo

Parte da informação que identifica cada arquivo nem sempre estava preenchida no nome, porque é um dado mutável e nem sempre estava disponível no momento da geração.

As pessoas precisavam buscar por critérios variados, alguns estruturados, outros por palavra-chave dentro do conteúdo, e nada disso estava exposto no nome do arquivo

Eram milhões de arquivos espalhados em containers diferentes, varrer linearmente era inviável.

Em resumo: tínhamos os dados, mas eram efetivamente invisíveis.

A solução

Construí um pipeline em .NET 9 que varre o storage e indexa todo o conteúdo em um cluster Elasticsearch (rodando em Kubernetes via ECK
Operator), com mapping otimizado para texto em português (analyzer com
stemmer, asciifolding e stopwords em PT-BR). O resultado é busca textual
em milhões de documentos em tempo real, mesmo quando o termo aparece
apenas no meio de uma seção específica do conteúdo.

Os pontos de design que fizeram diferença

Pipeline producer/consumer com System.Threading.Channels
Producer lista arquivos paginado, workers em paralelo baixam e parseiam em streaming, e bulk indexer envia batches pro Elastic. Channels bounded controlam pressão de memória.

Parser tolerante a dados sujos
Os arquivos históricos vinham com toda sorte de inconsistência: HTML entities, campos ausentes, datas inválidas, números como string, ordem de seções variável. Implementei discriminated union ParseResult (Success/Skipped/Failed) com helpers TryGet defensivos.
Política: indexa o que conseguiu, descarta apenas o irrecuperável, nunca derruba o pipeline por um arquivo ruim.

Busca híbrida em duas camadas
Quando o termo digitado tem um padrão estruturado, a API consulta o próprio storage (prefix lookup nativo, extremamente rápido) e o Elastic em paralelo. Resultados unidos: hits do storage no topo, hits textuais abaixo. O melhor de dois mundos sem latência adicional.

Boosts diferenciados por campo no Elastic
Match em campos estruturados tem boost maior. Match em texto solto tem boost menor. Resultado: busca por uma palavra específica sobe primeiro quem tem essa palavra em campo identificador, e só depois quem mencionou em texto livre.

Estratégia de alias para reindexação sem downtime
Cada carga gera um índice físico novo (com timestamp no nome) e o alias é trocado atomicamente no final. Permite reprocessar o histórico inteiro sem afetar produção.

Checkpointing stateless
Cada partição tem seu progresso salvo em storage externo. Se o pod morrer no meio da carga, retoma exatamente de onde parou. Sem volumes persistentes, sem estado local.

Highlights com fragmentos contextuais
Quando a busca casa em texto livre, o Elastic retorna trechos do conteúdo com a palavra encontrada destacada. A interface mostra o contexto direto na lista de resultados, sem precisar abrir cada item para descobrir por que ele apareceu.

🤖 O papel da IA nesse processo

Não vou fingir que cheguei nessa arquitetura sozinho em uma tarde. Usei
LLM como par técnico ao longo de todo o caminho, e a forma como usei
fez toda a diferença no resultado.

Onde a IA ajudou de verdade

Brainstorming de trade-offs arquiteturais
"Mensageria entre processos faz sentido aqui ou é overhead?", "Cursor pagination ou from/size pra infinite scroll?", "Alias com swap ou reindex in-place?".
Em vez de só pedir resposta, debati cada decisão e pesei prós e contras. A IA é excelente como sparring de design.

Análise crítica do código existente
O projeto inicial tinha mais peças do que precisava. Pedi uma análise técnica completa, code smells, dead code, bugs latentes, aderência a boas práticas. Saiu um documento de diagnóstico priorizado por severidade. Decidi simplificar a arquitetura com base nesse diagnóstico.

Modelagem do parser tolerante
Os cenários de dados sujos foram enumerados de forma exaustiva e cada um virou um caso de teste antes da implementação. Test-driven, mas com IA gerando o checklist.

Mapping do Elasticsearch
Definir analyzer correto pra português, decidir entre tipos de campo, projetar nested vs flat, é o tipo de decisão onde experiência prévia conta muito. Conversar com a IA acelerou em horas o que levaria dias de leitura de docs.

Prompts estruturados para agente de codificação
Quebrei a implementação em fases, cada uma com prompt detalhado contendo arquitetura alvo, decisões já tomadas, restrições, e ordem de execução. Resultado: o agente executou sem perder contexto e sem inventar.

Onde a IA NÃO substituiu o engenheiro

Decisões de negócio (volumes reais, padrões de acesso, regras de tratamento de exceções específicas do domínio)
Validar suposições contra a realidade do projeto (rodar build, ler logs, executar queries pra verificar comportamento)
Conhecer a infra real (capacidade dos volumes, classes de storage disponíveis, limites do cluster)
Priorizar segurança (a IA aponta riscos, mas a decisão de parar tudo pra resolver é humana)

A lição mais importante

IA é multiplicador, não substituto. Quem souber fazer perguntas certas, validar respostas e contextualizar com a realidade do projeto extrai muito valor. Quem só pede "me dá a solução" recebe código genérico que não resolve o problema real.

Stack utilizada

.NET 9 (Worker Service + ASP.NET Core)
Azure Blob Storage (origem dos dados)
Elasticsearch 8.x em Kubernetes via ECK Operator
Azure Table Storage (checkpoint stateless)
SDK oficial do Elastic (tipado)
System.Threading.Channels (pipeline assíncrono in-process)
Claude (sparring técnico e análise de código)
Claude Code (execução guiada por prompts estruturados)

Lições que valeram o post

Dados reais são sujos. Investi mais tempo projetando tolerância a inconsistências do que no pipeline em si. E foi o tempo mais bem gasto, em produção, um único arquivo malformado não pode derrubar uma carga em larga escala.

Mensageria nem sempre é a resposta. Para uma carga histórica única + ingestão futura via eventos do próprio storage, removi a camada de filas intermediária e simplifiquei para um indexer mais direto. Menos infra, menos custo, mais simples de testar.

Storage tem capacidades subutilizadas. O prefix lookup nativo do storage é absurdamente rápido e barato. Combinar isso com Elastic para o resto deu uma estratégia híbrida que nenhum dos dois sozinho daria.

Reindexar sem downtime é decisão arquitetural, não otimização. Resolver isso com alias desde o dia 1 me poupou de um problema futuro que apareceria do nada.

IA não pensa por você, mas amplifica quem pensa. O diferencial está em fazer as perguntas certas, contextualizar com seu projeto e validar tudo na prática.