DEV Community: Filipi Firmino

Saga Pattern: Consistência de Dados em Microsserviços de Verdade

Filipi Firmino — Sat, 01 Nov 2025 14:48:41 +0000

Bora falar de Sagas?

Garantir consistência de dados em sistemas distribuídos é, sem exagero, um dos maiores perrengues que a gente enfrenta quando entra no mundo dos microsserviços. É tipo tentar manter várias bandas tocando juntas sem maestro — cada uma no seu ritmo, mas tudo tem que soar em harmonia.
E é aí que entra o Saga Pattern: um jeito moderno e bem pragmático de coordenar serviços diferentes, sem perder escalabilidade nem resiliência.

🤔 Por que a gente precisa de Sagas?

Num monolito, a vida é mais simples: tudo roda num banco central, transações ACID cuidam da consistência e tá tudo certo.
Mas em microsserviços... cada domínio tem seu próprio banco. Então, imagina fechar um pedido de e-commerce — você precisa mexer em pedido, pagamento, estoque e entrega, tudo ao mesmo tempo e de forma sincronizada.
Se uma dessas etapas falha, tipo o pagamento passa, mas o estoque não tá disponível... pronto, o sistema fica num estado meio zumbi.

O Saga Pattern resolve exatamente isso: ele evita esses cenários "meio do caminho", garantindo que, se algo der errado, o sistema saiba como se recuperar — compensando as ações e voltando pra um estado consistente.

⚙️ Como o Saga Pattern funciona na prática

A ideia é dividir uma grande transação em várias transações locais.
Cada microserviço faz sua parte (de forma ACID local) e, se alguma etapa der ruim, o sistema executa transações compensatórias pra desfazer o que já foi feito.

Assim, mesmo com falhas ou timeouts, o sistema não quebra — ele se ajusta e segue a vida.

Em resumo:

Cada serviço cuida da sua transação local;
A comunicação entre eles acontece por eventos ou comandos;
Se algo falha, rola compensação e nada fica “órfão” no sistema.

Tipos de Sagas: Coreografia vs Orquestração

Coreografada:
Cada serviço reage a eventos e publica seus próprios — tipo uma dança sincronizada sem maestro.
É leve e funciona bem pra fluxos simples, mas conforme o sistema cresce, vira um caos entender quem chama quem.

Orquestrada:
Aqui entra um “maestro”: o orquestrador.
Ele coordena o fluxo, chama os serviços (síncrono ou assíncrono), espera respostas e dispara compensações quando algo falha.
Esse modelo é ótimo pra cenários mais críticos — tipo financeiro, pagamentos ou e-commerce de grande porte — porque dá rastreabilidade e facilita observabilidade.

🔄 Ciclo de Vida e Estado

Uma boa implementação de saga geralmente usa máquinas de estado pra acompanhar tudo:
Iniciado → Reservando estoque → Pagando → Entregando → Finalizado.

Isso garante:

Idempotência (se rodar duas vezes, o resultado é o mesmo),
Resiliência (suporte a retries, timeouts, intervenção manual),
Auditoria (você sabe exatamente onde algo deu ruim).

🔁 Compensações: o segredo da consistência

Pensa assim: se o pagamento falha, o sistema automaticamente desfaz o que já fez — tipo cancelar o pedido, liberar o estoque e reembolsar o valor.
Essas ações compensatórias são o coração do Saga Pattern e o que garante que o sistema continue íntegro, sem dados zumbis vagando pelo banco.

⚠️ Desafios e Boas Práticas

Alguns pontos pra ficar de olho:

Dual Write: gravar no banco e publicar evento ao mesmo tempo pode dar ruim se rolar falha no meio. Padrões como Outbox ou Change Data Capture ajudam muito aqui.

Observabilidade: log detalhado, métricas e tracing distribuído são obrigatórios.
Idempotência: sempre projete handlers que suportem reexecuções sem causar bagunça.
Compensações bem definidas: se tem CobrarPedido(), precisa ter EstornarCobranca().

Se você tá no ecossistema .NET, existem várias opções pra implementar sagas:

MassTransit (integra bem com RabbitMQ, Azure Service Bus, etc.);
NServiceBus;
Ou até usando Dapr e Azure Durable Functions, se quiser algo mais workflow-oriented.

A escolha entre coreografia e orquestração vai depender do cenário — se o foco é rastreabilidade e controle, orquestração costuma ganhar.

💡 Exemplo prático (pseudocódigo com MassTransit)

public class PedidoSaga : MassTransitStateMachine<PedidoState>
{
    public PedidoSaga()
    {
        InstanceState(x => x.Status);

        Initially(
            When(PedidoCriado)
                .Then(context => context.Instance.PedidoId = context.Data.PedidoId)
                .Publish(context => new ReservarEstoque { PedidoId = context.Instance.PedidoId })
                .TransitionTo(Reservando)
        );

        During(Reservando,
            When(EstoqueReservado)
                .Publish(context => new ProcessarPagamento { PedidoId = context.Instance.PedidoId })
                .TransitionTo(Pagando),

            When(ReservaFalhou)
                .Publish(context => new CancelarPedido { PedidoId = context.Instance.PedidoId })
                .Finalize()
        );

        SetCompletedWhenFinalized();
    }
}

No modelo coreografado, cada serviço publicaria eventos e escutaria eventos de outros, agindo de forma independente:

PedidoCriado → Evento:PedidoCriado → Serviço Estoque responde
 (EstoqueReservado) / (FalhaReservaEstoque)

Quando (e por que) usar ou evitar uma Saga?

Use saga quando houver múltiplos serviços e a consistência dos dados entre eles for obrigatória para o negócio;
Evite em cenários de baixa criticidade ou quando a implementação e manutenção do padrão trouxerem mais complexidade que benefícios.

Conclusão

O Saga Pattern não é bala de prata, mas está entre os padrões mais robustos e pragmáticos para lidar com consistência de dados distribuídos em microsserviços, especialmente em cenários críticos como e-commerce e financeiro. Aplicado de forma consciente, transforma sistemas frágeis em soluções resilientes, auditáveis e evolutivas.

🚫 A Armadilha dos Tipos Primitivos: Como Object Calisthenics Pode Salvar seu Código

Filipi Firmino — Sun, 26 Oct 2025 23:01:17 +0000

Já parou para pensar quantas vezes você usou uma simples decimal para representar um preço, string para um SKU ou int para uma quantidade no seu código? 🤔

Se a resposta foi "várias vezes" (e provavelmente foi), você pode estar caindo numa armadilha muito comum: a obsessão por tipos primitivos! Essa é uma das regras mais importantes do Object Calisthenics que pode transformar completamente a qualidade do seu código.

🎯 O Que é Object Calisthenics?

Object Calisthenics é como uma "academia para o seu código"! 💪 Criado por Jeff Bay, é um conjunto de 9 regras que funcionam como exercícios para tornar seu código mais orientado a objetos e próximo dos princípios SOLID.

As 9 regras são:

Apenas um nível de indentação por método
Não use a palavra-chave ELSE
Encapsule todos os tipos primitivos e Strings ⭐ (nosso foco hoje!)
Coleções como objetos de primeira classe
Um ponto por linha
Não abrevie
Mantenha todas as entidades pequenas
Não mais que duas variáveis de instância por classe
Evite getters/setters/properties

🚨 O Problema: Obsessão por Tipos Primitivos

Cenário Típico (que você já viu mil vezes)

public class Product
{
    private string _name;
    private decimal _price;
    private int _stock;
    private string _sku;

    public Product(string name, decimal price, int stock, string sku)
    {
        // Validação do nome
        if (string.IsNullOrWhiteSpace(name) || name.Length < 3)
            throw new Exception("Nome do produto inválido");

        // Validação do preço
        if (price <= 0)
            throw new Exception("Preço deve ser maior que zero");

        // Validação do estoque
        if (stock < 0)
            throw new Exception("Estoque não pode ser negativo");

        // Validação do SKU (aquela validação chata)
        if (string.IsNullOrWhiteSpace(sku) || !Regex.IsMatch(sku, @"^[A-Z0-9\-]+$"))
            throw new Exception("SKU inválido");

        _name = name;
        _price = price;
        _stock = stock;
        _sku = sku;
    }
}

😱 Os Problemas Dessa Abordagem

1. Código Duplicado Everywhere
Precisa criar um OrderItem? Vai ter que copiar todas essas validações de novo!

2. Responsabilidade Confusa
Por que diabos um Product precisa saber como validar SKU? 🤯

3. Violação do Princípio Aberto-Fechado
Se a regra de validação de preço mudar, você vai ter que mexer na classe Product. E se tiver mais 10 classes usando preço? Boa sorte! 😅

4. Classe Gigante
Sua classe vai ficar enorme sem ter nenhum comportamento realmente relacionado ao Product.

✨ A Solução: Value Objects

Criando um Preço que se Valida

using System;

public class Price
{
    private readonly decimal _value;

    public Price(decimal value)
    {
        if (value <= 0)
            throw new ArgumentException("Preço deve ser maior que zero");

        _value = value;
    }

    public decimal GetValue() => _value;

    public Price Add(Price other) => new Price(_value + other._value);
    public Price ApplyDiscount(decimal percentage) 
        => new Price(_value * (1 - percentage / 100));

    public override string ToString() => _value.ToString("C2");
}

SKU que Sabe se Comportar

using System;
using System.Text.RegularExpressions;

public class SKU
{
    private readonly string _value;

    public SKU(string sku)
    {
        Validate(sku);
        _value = sku;
    }

    private void Validate(string sku)
    {
        if (string.IsNullOrWhiteSpace(sku))
            throw new ArgumentException("SKU não pode ser vazio");

        if (!Regex.IsMatch(sku, @"^[A-Z0-9\-]{5,20}$"))
            throw new ArgumentException("SKU deve ter entre 5 e 20 caracteres alfanuméricos");
    }

    public string GetValue() => _value;

    public override string ToString() => _value;
    public override bool Equals(object obj) 
        => obj is SKU sku && _value == sku._value;
    public override int GetHashCode() => _value.GetHashCode();
}

Estoque com Regras de Negócio

using System;

public class Stock
{
    private readonly int _value;

    public Stock(int quantity)
    {
        if (quantity < 0)
            throw new ArgumentException("Estoque não pode ser negativo");

        _value = quantity;
    }

    public int GetValue() => _value;

    public bool IsAvailable() => _value > 0;
    public bool IsLowStock(int threshold = 10) => _value <= threshold && _value > 0;
    public bool IsOutOfStock() => _value == 0;

    public Stock Remove(int quantity)
    {
        if (quantity > _value)
            throw new InvalidOperationException("Estoque insuficiente");
        return new Stock(_value - quantity);
    }

    public Stock Add(int quantity) => new Stock(_value + quantity);
}

Nome de Produto com Validações

using System;

public class ProductName
{
    private readonly string _value;

    public ProductName(string name)
    {
        if (string.IsNullOrWhiteSpace(name))
            throw new ArgumentException("Nome não pode ser vazio");

        if (name.Length < 3)
            throw new ArgumentException("Nome deve ter pelo menos 3 caracteres");

        if (name.Length > 100)
            throw new ArgumentException("Nome não pode ter mais de 100 caracteres");

        _value = name.Trim();
    }

    public string GetValue() => _value;

    public override string ToString() => _value;
    public override bool Equals(object obj) 
        => obj is ProductName name && _value == name._value;
    public override int GetHashCode() => _value.GetHashCode();
}

🎉 O Resultado: Product Renovado

public class Product
{
    private readonly ProductName _name;
    private readonly Price _price;
    private readonly Stock _stock;
    private readonly SKU _sku;

    public Product(ProductName name, Price price, Stock stock, SKU sku)
    {
        _name = name;
        _price = price;
        _stock = stock;
        _sku = sku;
    }

    public string GetName() => _name.GetValue();
    public decimal GetPrice() => _price.GetValue();
    public int GetStock() => _stock.GetValue();
    public string GetSKU() => _sku.GetValue();

    // Agora você pode ter comportamentos reais do Product!
    public bool CanBeSold() => _stock.IsAvailable();
    public bool NeedsRestock() => _stock.IsLowStock();
    public Price CalculateDiscountedPrice(decimal discount) => _price.ApplyDiscount(discount);
}

🚀 Como Usar na Prática

// Criação segura - qualquer valor inválido vai explodir na hora certa!
var name = new ProductName("Notebook Gamer XYZ");
var price = new Price(2999.99m);
var stock = new Stock(15);
var sku = new SKU("NGB-XYZ-2024");

var product = new Product(name, price, stock, sku);

// Comportamentos ricos!
if (product.CanBeSold())
{
    var discountedPrice = product.CalculateDiscountedPrice(10);
    Console.WriteLine($"Produto disponível por {discountedPrice}");
}

if (product.NeedsRestock())
{
    Console.WriteLine("⚠️ Produto com estoque baixo - reabastecer!");
}

🎯 Benefícios Que Você Vai Ganhar

✅ Reutilização Total

Precisa de Price em 20 classes? Use o mesmo Price object em todas!

✅ Manutenção Centralizada

Mudou a regra de validação? Só mexe em um lugar!

✅ Testes Mais Fáceis

Teste a validação do SKU separadamente do Product. Cada coisa no seu lugar!

✅ Código Mais Expressivo

product.CanBeSold() é muito mais claro que verificar product.Stock > 0

✅ Fail-Fast

Erros são detectados no momento da criação, não quando você menos espera.

⚠️ Cuidados e Bom Senso

Nem tudo precisa virar Value Object! 🧠

Se você tem um bool isActive no seu Product, não precisa criar uma classe IsActive. Use o bom senso!

Object Calisthenics são exercícios, não leis absolutas. A ideia é treinar seu pensamento orientado a objetos, não enlouquecer criando classe para tudo.

🎊 Conclusão

A regra "Encapsule todos os tipos primitivos" do Object Calisthenics não é sobre complicar seu código - é sobre deixá-lo mais robusto, reutilizável e expressivo!

Quando você para de usar decimal para preços, string para SKUs e int para quantidades e começa a criar objetos que representam conceitos reais do seu domínio, seu código ganha vida. Ele fica mais fácil de entender, testar e manter.

🚀 Próximos Passos

Identifique os tipos primitivos no seu código atual
Pergunte-se: "Esse valor tem regras de negócio? Precisa de validação?"
Crie Value Objects para os casos que fazem sentido
Refatore gradualmente - não precisa fazer tudo de uma vez!

Lembre-se: você não escreve código apenas para a máquina, mas para pessoas (incluindo você do futuro)! 😉

Framework novo todo mês: evolução ou roda com adesivo novo?

Filipi Firmino — Tue, 05 Aug 2025 20:17:52 +0000

Sabe quando você entra no Twitter e vê alguém dizendo: “Nova stack JavaScript que vai revolucionar o mercado!”… e você nem aprendeu direito a anterior? Pois é. Parece que estamos presos em um looping infinito de frameworks, onde o hype chega antes da estabilidade e a documentação às vezes é só um post no Medium de 2017.

Hoje vamos falar da polêmica que todo dev já murmurou (ou gritou em silêncio): será que estamos realmente evoluindo, ou só refazendo a roda com nomes mais descolados?

🤹 O circo dos frameworks

A cada três scrolls no feed do LinkedIn ou X, surge um novo “meta-framework”, “turbo stack”, “minimal boilerplate” ou alguma variação disso. A promessa é sempre a mesma: ser mais performático, mais fácil, mais intuitivo, mais tudo. Mas será que alguém parou pra pensar se a gente precisava mesmo disso?

Um dev backend sênior que conheci uma vez me disse:

“Todo framework novo é como uma start-up: começa resolvendo um problema real, mas logo vira uma empresa tentando justificar sua existência.”

E ele não estava errado.

🧠 Por que caímos nesse ciclo?

Existem alguns fatores — técnicos, emocionais e até sociais — que explicam esse comportamento:

Curiosidade natural do dev: Aprender coisa nova dá aquele shot de dopamina. Parece que estamos “evoluindo” só por ter digitado npm install o-novo-do-momento.
FOMO (Fear of Missing Out): Ver todo mundo postando sobre o novo XJS faz a gente se sentir desatualizado. Gatilho da escassez ativado com sucesso. 😅
Prova social: Se grandes empresas usam, deve ser bom, né? (Spoiler: nem sempre.)
Síndrome do impostor inversa: “Se eu não estou aprendendo o novo framework, será que sou um dev de verdade?”

Resultado? Gente migrando de stack antes mesmo da anterior estar consolidada no projeto.

🧩 E o problema não é o framework...

Antes que você pense que isso é um manifesto reacionário do tipo “voltemos ao jQuery”, calma lá.

Frameworks são importantes, sim. Eles abstraem complexidade, padronizam boas práticas e impulsionam a comunidade. O problema está no consumo desenfreado, não na criação. É como querer trocar de carro toda semana só porque lançaram um com farol de LED.

Nem toda mudança é evolução. E nem toda novidade vale a pena pra você, agora.

🔍 Então o que fazer?

A chave aqui é intencionalidade. Em vez de correr atrás de tudo o que brilha, que tal:

Investigar a real necessidade da stack antes de adotar algo novo.
Estudar fundamentos, que nunca saem de moda (HTTP, arquitetura, lógica de programação...).
Dominar bem uma stack antes de saltar para outra. Ser especialista ainda é sexy, viu?
Entender o contexto do projeto e da equipe. Às vezes, o melhor framework é aquele que TODO MUNDO CONSEGUE USAR.

💬 Conclusão: nem toda buzzword vira legado

O mundo dev tem um ritmo alucinante — e parte disso é o que torna tudo tão instigante. Mas também pode ser exaustivo se você entrar no jogo do hype como se fosse um campeonato.

Você não precisa conhecer todos os frameworks para ser um bom dev. Precisa saber escolher quando usar algo novo — e quando dizer: “Tá bom assim, obrigado.”

Então da próxima vez que surgir uma nova lib com nome de animal selvagem misturado com sigla obscura, respira fundo. Pergunta pra si mesmo:

Isso resolve um problema real ou só alimenta minha ansiedade de estar por dentro?

“Framework bom é igual café: não precisa ser o mais caro, só precisa funcionar bem no seu dia a dia.” – Um dev cansado, provavelmente.

Reinventando a roda: por que todo projeto quer criar "a sua própria arquitetura"?

Filipi Firmino — Mon, 04 Aug 2025 22:06:08 +0000

“Aqui a gente usa uma arquitetura que a gente mesmo criou...”

Se você já ouviu (ou falou) isso, provavelmente já está sentindo um leve arrepio no teclado. 😅 E se ainda não ouviu, prepare-se: é questão de tempo até topar com um sistema que mais parece uma ficção científica mal escrita.

Vamos conversar sobre essa mania quase ritualística que muitos times devs têm de criar A Arquitetura Suprema™, única, personalizada, como se o projeto fosse uma startup unicórnio em Marte — quando, na real, é um CRUD de orçamento com autenticação e um botão de exportar pra Excel.

O ego do dev arquiteto (e o custo disso)

No fundo, no fundo, criar uma arquitetura do zero dá aquela sensação boa de poder. É como brincar de Lego: você decide onde vai cada pecinha. Só que, diferente do Lego, aqui o tempo custa caro e o time do futuro vai te xingar em 3 linguagens diferentes.

Arquitetura customizada demais, sem seguir padrões consolidados como DDD, Clean Architecture ou até um MVC bem feito, vira dívida técnica disfarçada de inovação. Você pode até convencer o time de que aquele handler mágico com 5 middlewares e 12 interceptadores é o caminho — mas daqui 6 meses, quando outro dev tentar dar manutenção, vai ser tipo montar um quebra-cabeça com peças de jogos diferentes.

O paradoxo da inovação: nem tudo precisa ser novo

Aqui entra um dos gatilhos mentais mais traiçoeiros do mundo tech: o da curiosidade. O desenvolvedor vê uma arquitetura no Medium, ou assiste uma talk sobre microserviços em Kubernetes, e pronto — quer aplicar isso no sistema de controle de ponto do RH.

Mas inovação sem propósito é só complexidade disfarçada.

Você não ganha pontos por usar 3 filas Kafka, 2 sagas e uma pitada de event sourcing num projeto que tem 50 usuários ativos. Isso não é arquitetura moderna — é overengineering gourmet. E a conta vai chegar. Ah, vai.

"Mas aqui é diferente..."

Todo dev já ouviu (ou disse) isso. É o mantra da customização desenfreada: “nosso caso é especial”. Spoiler: 90% das vezes, não é.

Empresas bem-sucedidas, de todos os tamanhos, adotam padrões. Do iFood ao Nubank, do Magazine Luiza ao seu sistema interno de gestão de planilhas — todos ganham em previsibilidade, reuso e facilidade de onboard.

Quando você foge dos padrões por "excesso de criatividade", está empurrando seu projeto pro isolamento técnico. E sabe o que mora no isolamento? Bugs, burnout e devs com vontade de mudar de time.

Ok, mas e a tal da flexibilidade?

Agora você pode estar pensando: “Então é pra fazer tudo igual sempre?”. Calma, jovem padawan. Flexibilidade é importante, sim. Mas ela precisa nascer de um alicerce sólido — e não de um castelo de areia feito com conceitos que só você entende.

Padrões servem pra você ganhar tempo com o que realmente importa: regras de negócio, performance, experiência do usuário. Não pra você perder semanas discutindo onde vai ficar a camada de orquestração do seu Domain Notification Aggregator (que, sejamos honestos, ninguém além de você entende).

Conclusão: menos show, mais código sustentável

No fim das contas, arquitetura não é palco pra ego. É fundação. E fundação boa é aquela que permite que outras pessoas construam em cima — sem medo, sem dor e sem precisar te ligar no domingo à noite pra entender como fazer um PUT funcionar.

A real maturidade de um time está em saber quando inovar e quando apenas seguir o que já funciona.

E antes de criar o seu próximo “framework próprio com arquitetura que a gente bolou aqui”, dá uma olhada em como o mercado está resolvendo esse problema. Talvez a resposta esteja ali, no bom e velho Clean Architecture com um toque de simplicidade.

Afinal, o que é mais sexy do que um sistema que funciona, é escalável e qualquer dev consegue entender?

Nada. Absolutamente nada. ❤️

"Simplicidade é o último grau de sofisticação."

– Leonardo da Vinci (e todo dev que já limpou a bagunça de um sistema “visionário”)

Quer continuar esse papo? Me conta nos comentários: qual foi a arquitetura mais bizarra que você já viu em produção? 😬

Async/Await na prática: por que seu código 'assíncrono' ainda está lento?

Filipi Firmino — Sat, 02 Aug 2025 16:56:10 +0000

Você colocou async no método, await em tudo quanto é canto, a IDE parou de reclamar... mas o sistema continua lento. Dá até vontade de gritar: “Tô usando async! Por que isso ainda parece síncrono com insônia?”

Calma, dev. Bora entender onde tá o bug invisível (e como evitá-lo no mundo real do .NET).

Primeiro, um alerta: `async/await` não é magia negra ⚠️

Sim, a sintaxe parece um encantamento de Hogwarts: await AbrirConexaoComBancoAsync();
Mas por trás disso, tem threads, tasks, contextos de sincronização, e um compilador trabalhando mais do que o estagiário em semana de entrega.

E é aí que mora o perigo: muita gente usa async/await achando que está paralelizando tudo, quando na real está só empilhando promessas mal resolvidas.

Entendendo a armadilha: o falso assíncrono

Veja este exemplo clássico de cilada:

public async Task<List<Usuario>> GetUsuariosAsync()
{
    var lista = new List<Usuario>();

    foreach (var id in listaDeIds)
    {
        var usuario = await _servicoUsuarios.BuscarPorIdAsync(id);
        lista.Add(usuario);
    }

    return lista;
}

Você olha isso e pensa:

“Olha que lindo, tudo assíncrono!”

Mas não. Tá tudo sequencial. Um await só roda depois que o outro termina.
Isso é o equivalente a usar Uber pra ir pra padaria da esquina. Funciona? Funciona. Mas tá longe de ser eficiente.

A solução? `Task.WhenAll` na sua vida 🧠

Se o serviço permite chamadas em paralelo, faça isso:

public async Task<List<Usuario>> GetUsuariosAsync()
{
    var tarefas = listaDeIds
        .Select(id => _servicoUsuarios.BuscarPorIdAsync(id));

    var resultados = await Task.WhenAll(tarefas);

    return resultados.ToList();
}

Agora sim: todas as requisições estão rolando ao mesmo tempo, aproveitando o que a programação assíncrona tem de melhor.

Outro vilão oculto: o tal do `ConfigureAwait(false)`

Se você tá desenvolvendo em ASP.NET Core, usar ou não usar ConfigureAwait(false) pode ser a diferença entre uma app escalável ou uma panela de pressão explodindo.

Por padrão, await tenta capturar o contexto de sincronização original (tipo, o contexto do thread do request).
Mas no ASP.NET Core, você não precisa disso. E evitar essa captura libera a thread mais cedo.

Exemplo:

await _algumaCoisa.FazAlgoAsync().ConfigureAwait(false);

Menos overhead. Mais performance. Mais paz.

Tá, mas quando NÃO usar paralelismo?

Nem todo async precisa ser paralelo.

Se os métodos compartilham estado (tipo, gravam na mesma lista), melhor evitar.
Se sua fonte de dados limita chamadas concorrentes (como alguns bancos ou APIs), paralelismo pode prejudicar.
Se o serviço for "assíncrono em aparência, mas síncrono por dentro", também não adianta muito...

Ou seja: assíncrono é ótimo — mas nem tudo que brilha é Task.Run().

Moral da thread

Async não resolve tudo, mas bem usado é poder puro ⚙️

O uso de async/await no C# é uma das maiores evoluções da linguagem.Mas usá-los de forma ingênua é como dirigir uma Ferrari com freio de mão puxado: bonito por fora, frustrante por dentro.

Seja esperto. Entenda o que tá rodando por baixo.
Meça, monitore, e use as ferramentas com propósito.

Seu sistema, seu time e seu cliente vão agradecer (e talvez até o seu GC também).

P.S.:
Se você leu até aqui e pensou “puts, eu faço isso no meu código😬” — respira. Refatora.
E compartilha esse artigo com o time antes que mais alguém invente de colocar async void no Controller.

Dev vai perder o emprego por causa da IA? Ou é só drama do Twitter?

Filipi Firmino — Fri, 01 Aug 2025 21:18:15 +0000

Você já abriu o X (ex-Twitter), viu um post tipo “Copilot escreve melhor que muito júnior por aí”, e sentiu aquele frio na espinha? Calma. Respira. Esse papo de “IA vai substituir os devs” já virou o novo “o HTML vai morrer”.

Mas sim, temos que conversar sobre isso com seriedade (e memes, se possível).

IA escreve código. E daí?

Sim, o Copilot completa código. O ChatGPT te dá um CRUD inteiro em segundos. O Gemini e o Claude agora até explicam lógica recursiva com exemplos de bolo de cenoura. Tá assustador? Um pouco. Mas será que isso significa o fim dos devs?

Spoiler: não. Significa o fim dos devs que só decoram stackoverflow.

A IA tá aqui pra automatizar o braçal, o repetitivo, o que você faz de olhos fechados. E isso não é o fim. É só o shift + tab da profissão: um recuo estratégico pra gente pensar em mais alto nível.

E o júnior, como fica?

Muita gente fala: “Mas e o dev júnior? Como vai aprender se a IA faz tudo?”

Bom... se você depender de digitar for (int i = 0; i < 10; i++) 10 mil vezes pra aprender, talvez o problema não seja a IA. Talvez a gente precise repensar como ensinamos programação.

A boa notícia é que a IA também pode ser o melhor professor que você já teve. Te explica, te corrige, não julga quando você pergunta pela décima vez o que é null.

A má notícia? Agora não tem mais desculpa pra não evoluir. 😅

O futuro do dev: mais estrategista, menos digitador

Quem vai continuar relevante?

Quem entende o porquê das coisas, não só o "como".
Quem sabe tomar decisões técnicas e arquiteturais, mesmo com um assistente sugerindo caminhos.
Quem usa IA como aliada, e não como muleta.
Quem domina soft skills: comunicação, colaboração, visão de produto.

Porque no fim das contas, saber apertar botões é diferente de saber resolver problemas. E resolver problema é o que as empresas pagam pra você fazer.

Devs não vão sumir. Mas os “copiadores de stackoverflow” vão.

A IA não está te substituindo. Ela está substituindo quem não evolui.

Lembra quando diziam que o Excel ia acabar com os contadores? E o AutoCAD ia matar os arquitetos? Então. Eles continuam aí. Mas os melhores aprenderam a usar essas ferramentas a seu favor.

É isso que vai acontecer com a IA: quem aprender a pilotar a máquina, vai mais longe.

Moral do bug: não é sobre a IA — é sobre o que você faz com ela

Pare de brigar com a IA como se ela fosse seu concorrente. Ela não quer seu trampo. Ela quer seu tempo. Quer te dar espaço pra criar, arquitetar, explorar ideias novas. Enquanto ela cuida do resto.

Então na próxima vez que você ouvir “a IA vai te substituir”, responda:

“Só se o cara for igual a um autocomplete. Eu sou mais do que isso.” 😉

P.S.: Se esse texto te deu aquele alívio existencial, compartilha com um amigo que tá surtando achando que o GPT vai virar Tech Lead dele. Bora respirar juntos.

Mentores que não codam: dá pra confiar ou é cilada, Bino?

Filipi Firmino — Thu, 31 Jul 2025 18:13:00 +0000

Sabe aquele mentor famosinho no LinkedIn que fala bonito sobre carreira dev, mas que nunca mostrou um git log ou um for na vida? Pois é… esse artigo é pra você que já se pegou pensando: "Será que eu devo ouvir alguém que não escreve código?"

Bora conversar sobre isso sem alfinetada gratuita, mas com umas verdades que talvez incomodem -um pouquinho só, prometo.

“Na minha época, isso tudo era mato...” — a sabedoria ou a enrolação?

Mentoria é um negócio mágico. Ter alguém que te guia, te mostra caminhos, evita que você caia em armadilhas... é como ter um GPS emocional e técnico na jornada. Mas, como todo bom GPS, ele precisa estar atualizado.

E aí começa o dilema: se o mentor não mexe mais com código, será que ele ainda entende os desafios reais de hoje? Tipo, como explicar burnout por causa de 34 deploys por semana se a pessoa nunca usou GitHub Actions ou enfrentou um Jira caótico às 17h de sexta?

A comparação é cruel, eu sei. Mas ela é necessária.

Nem todo mentor precisa ser um “coder ninja” (mas ajuda bastante)

Calma, respira. Não tô dizendo que só vale escutar quem tá com o VS Code aberto 24h por dia. Longe disso. Conhecimento teórico, vivência em outras áreas, visão de negócios... tudo isso é valiosíssimo.

Mas sejamos sinceros: quando o mentor nunca passou por nada parecido com o que você vive hoje, o risco de virar conselho genérico disfarçado de sabedoria é altíssimo.

É tipo pedir dica de arquitetura de microsserviços pra quem parou no monolito do Delphi. Pode vir algo útil? Até pode. Mas não seria mais prático (e seguro) conversar com alguém que realmente vive isso?

O que realmente importa num mentor?

Mais do que saber programar (embora isso seja ótimo), um bom mentor precisa:

Ter empatia de contexto: entender o que você tá passando hoje, e não só o que ele passou há 10 anos.
Compartilhar experiências com vulnerabilidade: não é só contar vitórias, é mostrar os tombos também.
Estar em aprendizado constante: o mentor que estagnou vira estátua, não guia.
Saber ouvir mais do que falar: porque às vezes, o melhor conselho é só fazer a pergunta certa.

Ah, e se ele ainda codar de vez em quando, aí é bônus nível épico.

A real: mentor bom não precisa saber tudo — só precisa estar disposto a caminhar com você

No fim do dia, o código muda, as ferramentas evoluem, mas os dilemas continuam os mesmos: insegurança, medo de não dar conta, decisões difíceis, síndrome do impostor, burnout, pressão.

Um mentor não serve só pra te ensinar a usar async/await, mas pra te lembrar que tá tudo bem se hoje você só conseguiu abrir o editor e tomar um café. Que todo mundo tem fases. E que crescimento de verdade vem mais de conversa sincera do que de fórmulas mágicas.

Conclusão que vale ouro (sem depender de pull request)

Confie em mentores que se importam com você como pessoa, não só como um “júnior querendo chegar lá”.

Desconfie de quem nunca mostra o bastidor, mas vive dando palestra sobre “ser sênior em 6 meses”.

E mais importante: seja também o mentor que você gostaria de ter tido.

O mercado precisa de menos palestrinha e mais gente de verdade.

P.S.: Tem algum mentor que te ajudou mesmo sem codar todos os dias? Manda esse artigo pra ele com um “valeu!” no assunto. Reconhecimento também é prática sênior 😉

Será que eu sei mesmo programar?

Filipi Firmino — Wed, 30 Jul 2025 23:16:24 +0000

🧠 “Será que eu sei mesmo programar?” — a verdade sobre a síndrome do impostor no mundo dev

Você já olhou praquele código que escreveu ontem e pensou: “quem foi o gênio que escreveu isso?”... e aí percebeu que foi você mesmo? Pois é. Bem-vindo ao clube nada exclusivo (mas pouco falado) da síndrome do impostor
— aquele bug mental que vive dizendo que você não é bom o suficiente, mesmo com todos os testes passando em verde.

Talvez você esteja rindo com nervoso agora. E tudo bem. Vamos falar sobre isso com a leveza e sinceridade que esse tema merece.

A build falhou, mas não foi o código. Foi você (ou pelo menos é o que sua mente diz)

No mundo do desenvolvimento, é comum acharmos que todo mundo manja mais do que a gente. O cara do time que parece resolver tudo só com regex, a dev que faz live coding no Twitch, o amigo que fala de arquitetura como se estivesse explicando receita de pão... E aí, do nada, você se vê pensando: "O que eu tô fazendo aqui?"

Spoiler: se você tá se perguntando isso, é sinal de que provavelmente está exatamente onde deveria estar. Porque quem acha que já sabe tudo, geralmente não sabe o suficiente pra perceber o quanto ainda tem pra aprender. 🤷

"Mas eu não sei nem como esse código funciona!" — todo dev, toda semana

A síndrome do impostor é traiçoeira porque ela se adapta. No início da carreira, ela diz que você não manja nada. No meio da carreira, ela diz que todo mundo ao seu redor manja mais. No fim da carreira… bom, ela ainda tá lá dizendo que você teve sorte.

Esse sentimento de inadequação é mais comum do que parece. Sabe aquele dev que você admira no LinkedIn? Ele provavelmente também sente isso. Ele só aprendeu a conviver com o sentimento, como quem ignora aquele aviso do Windows pedindo pra atualizar.

A real é: todo mundo está improvisando em algum nível. O segredo não é eliminar a síndrome do impostor, mas aprender a usá-la como combustível. Se você sente que sabe pouco, talvez isso só signifique que você se importa em fazer bem feito. E isso já é meio caminho andado.

A mentira que te contaram: “Quando eu for sênior, isso vai passar”

Olha... não vai. Ou melhor, até pode passar, mas volta. Em outros formatos. Quando você vira sênior, o fantasma muda de roupa e aparece como o "medo de não estar liderando bem", "de não saber arquitetura direito", ou "de estar atrasado na IA quântica com Blockchain em Rust rodando no Kubernetes do metaverso". E tudo bem.

A grande sacada é entender que confiança não vem de saber tudo — vem de saber que você é capaz de aprender o que for necessário. É aquela skill secreta que não aparece no currículo, mas que todo bom dev precisa: a coragem de dizer "não sei" sem travar.

Então o que eu faço com esse bug mental?

Fale sobre isso. O simples ato de compartilhar esse sentimento com colegas ou mentores já é um "debug" poderoso.
Registre suas vitórias. Mantenha uma pastinha (física ou mental) com os projetos que deu conta, os bugs que matou, os PRs que foram aprovados de primeira.
Compare-se com seu eu de ontem, não com o dev do YouTube. Lembre-se: o vídeo editado de alguém nunca vai refletir a bagunça que é o processo real.
Dê tempo ao tempo. A confiança é acumulada como XP em um RPG — aos poucos, errando, tentando, caindo e levantando.

Moral da história? O impostor não vai embora, mas você pode colocá-lo no banco de trás.

A síndrome do impostor é tipo aquele linter chato: fica te lembrando das falhas, mas também te empurra pra melhorar. E no fundo, ela só existe porque você se importa. Porque quer entregar código limpo, entender o sistema, fazer bonito no review.

Então da próxima vez que ela aparecer, respira fundo e lembra: você não está sozinho nessa. E se duvidar, tá indo bem melhor do que imagina.

E se ainda não acredita em mim… olha só o tanto de gente compartilhando esse artigo dizendo “sou eu todinho”. 😉

P.S.: Se esse artigo falou contigo, manda praquele colega que vive se achando "juninho", mesmo sendo brabo. Bora desbugar essa mentalidade juntos.

CLT, PJ ou Freela? A treta mais antiga do TI depois de Tabs vs Spaces

Filipi Firmino — Mon, 28 Jul 2025 21:04:24 +0000

💼 CLT, PJ ou Freela? A treta mais antiga do TI depois de Tabs vs Spaces

Se você é dev e nunca parou pra pensar em qual modelo de contratação vale mais a pena… provavelmente você ainda tá no LinkedIn da forma errada.

A real é que no mundo moderno do desenvolvimento — especialmente se você manja de .NET, Python, JS, IA, automação, ou se tem uma API rodando na cabeça — as opções são muitas e cada uma tem suas tretas, vantagens e ciladas.

Vamos quebrar isso de forma leve (e um pouco sarcástica, porque né, a vida já é complexa demais sem humor).

🧑‍💻 CLT — “Contrato com Leveza... ou Tensão?”

CLT é aquele modelo que muita empresa ama, porque traz estabilidade e conformidade legal.

Mas pro dev? Nem sempre é 100% amor.

🟢 Pontos positivos:

Férias pagas (sim, você pode sumir 30 dias sem culpa)
13º salário, FGTS, plano de saúde, VR (alô iFood!)
Estabilidade (o famoso “carteira assinada” que acalma o coração da sua mãe)

🔴 Pontos negativos:

Salário líquido menor (impostos, o terror do dev que fez o curso de finanças com Excel)
Carga tributária absurda pro empregador (que podia virar aumento, né?)
Pouca flexibilidade em alguns casos

“O salário entra e já tem um boleto esperando ele na porta com um facão.”

💼 PJ — “Pode Jogar que o imposto é seu”

O famoso “Pessoa Jurídica” virou padrão em muitas startups e empresas que querem menos burocracia (e mais resultados).

🟢 Pontos positivos:

Salário maior (sem impostos CLTianos comendo metade)
Liberdade pra negociar, trabalhar remoto, até emitir nota ouvindo música eletrônica
Se organizar direitinho, dá pra pagar menos imposto legalmente

🔴 Pontos negativos:

Sem férias, sem 13º, sem "benefícios" (você é sua própria empresa)
Tem que pagar contador, emitir nota, cuidar do IR — é tipo ser dev e meio financeiro
Se der ruim, não tem seguro-desemprego pra te abraçar

“Hoje sou Dev, amanhã CEO de mim mesmo, depois de amanhã tô pagando DARF com lágrimas.”

🎨 Freela — o modo nômade dos devs criativos (e corajosos)

Freelancer é pra quem curte liberdade com adrenalina. Pode ser full time ou projeto por projeto.

🟢 Pontos positivos:

Liberdade total (trabalhar da praia, do café ou do quarto escuro às 3h)
Escolhe com quem trabalhar (em teoria)
Potencial de ganhar bem se souber se vender

🔴 Pontos negativos:

Instabilidade: um mês você fatura R$10k, no outro come miojo com criatividade
Tem que caçar cliente, lidar com prazo, contrato, cobrar (às vezes com jeitinho)
Tudo depende de você: disciplina, gestão, entrega, cobrar e ainda programar

“Trabalhar quando quiser... desde que queira trabalhar o tempo todo.”

🧠 Qual o melhor modelo então?

A resposta mais odiada do Stack Overflow também vale aqui: depende.

Quer estabilidade e não quer pensar em impostos? Vai de CLT.
Quer mais grana e topa lidar com papelada? PJ é teu lugar.
Quer liberdade total e tem veia empreendedora? Freela pode ser o caminho.

A verdade é que sua carreira é um produto. E você é o CEO.

DEV Community: Filipi Firmino

Saga Pattern: Consistência de Dados em Microsserviços de Verdade

Bora falar de Sagas?

🤔 Por que a gente precisa de Sagas?

⚙️ Como o Saga Pattern funciona na prática

Tipos de Sagas: Coreografia vs Orquestração

🔄 Ciclo de Vida e Estado

🔁 Compensações: o segredo da consistência

⚠️ Desafios e Boas Práticas

💡 Exemplo prático (pseudocódigo com MassTransit)

Quando (e por que) usar ou evitar uma Saga?

Conclusão

🚫 A Armadilha dos Tipos Primitivos: Como Object Calisthenics Pode Salvar seu Código

🎯 O Que é Object Calisthenics?

🚨 O Problema: Obsessão por Tipos Primitivos

Cenário Típico (que você já viu mil vezes)

😱 Os Problemas Dessa Abordagem

✨ A Solução: Value Objects

Criando um Preço que se Valida

SKU que Sabe se Comportar

Estoque com Regras de Negócio

Nome de Produto com Validações

🎉 O Resultado: Product Renovado

🚀 Como Usar na Prática

🎯 Benefícios Que Você Vai Ganhar

✅ Reutilização Total

✅ Manutenção Centralizada

✅ Testes Mais Fáceis

✅ Código Mais Expressivo

✅ Fail-Fast

⚠️ Cuidados e Bom Senso

🎊 Conclusão

🚀 Próximos Passos

Framework novo todo mês: evolução ou roda com adesivo novo?

🤹 O circo dos frameworks

🧠 Por que caímos nesse ciclo?

🧩 E o problema não é o framework...

🔍 Então o que fazer?

💬 Conclusão: nem toda buzzword vira legado

Reinventando a roda: por que todo projeto quer criar "a sua própria arquitetura"?

O ego do dev arquiteto (e o custo disso)

O paradoxo da inovação: nem tudo precisa ser novo

"Mas aqui é diferente..."

Ok, mas e a tal da flexibilidade?

Conclusão: menos show, mais código sustentável

Async/Await na prática: por que seu código 'assíncrono' ainda está lento?

Primeiro, um alerta: async/await não é magia negra ⚠️

Entendendo a armadilha: o falso assíncrono

A solução? Task.WhenAll na sua vida 🧠

Outro vilão oculto: o tal do ConfigureAwait(false)

Exemplo:

Tá, mas quando NÃO usar paralelismo?

Moral da thread

Dev vai perder o emprego por causa da IA? Ou é só drama do Twitter?

IA escreve código. E daí?

E o júnior, como fica?

O futuro do dev: mais estrategista, menos digitador

Devs não vão sumir. Mas os “copiadores de stackoverflow” vão.

Moral do bug: não é sobre a IA — é sobre o que você faz com ela

Mentores que não codam: dá pra confiar ou é cilada, Bino?

“Na minha época, isso tudo era mato...” — a sabedoria ou a enrolação?

Nem todo mentor precisa ser um “coder ninja” (mas ajuda bastante)

O que realmente importa num mentor?

A real: mentor bom não precisa saber tudo — só precisa estar disposto a caminhar com você

Conclusão que vale ouro (sem depender de pull request)

Será que eu sei mesmo programar?

🧠 “Será que eu sei mesmo programar?” — a verdade sobre a síndrome do impostor no mundo dev

A build falhou, mas não foi o código. Foi você (ou pelo menos é o que sua mente diz)

"Mas eu não sei nem como esse código funciona!" — todo dev, toda semana

A mentira que te contaram: “Quando eu for sênior, isso vai passar”

Então o que eu faço com esse bug mental?

Moral da história? O impostor não vai embora, mas você pode colocá-lo no banco de trás.

CLT, PJ ou Freela? A treta mais antiga do TI depois de Tabs vs Spaces

💼 CLT, PJ ou Freela? A treta mais antiga do TI depois de Tabs vs Spaces

🧑‍💻 CLT — “Contrato com Leveza... ou Tensão?”

💼 PJ — “Pode Jogar que o imposto é seu”

🎨 Freela — o modo nômade dos devs criativos (e corajosos)

🧠 Qual o melhor modelo então?

Primeiro, um alerta: `async/await` não é magia negra ⚠️

A solução? `Task.WhenAll` na sua vida 🧠

Outro vilão oculto: o tal do `ConfigureAwait(false)`