Luiz Carlos Faria | Canal

Hoje, 21h, no Canal .NET: Event Driven Architecture — o que você precisa entender antes de adotar. Nos últimos 13 anos trabalhando com mensageria e RabbitMQ, recuperei projetos de todos os tamanhos: Bancos, startups de música, dpvat, a integradoras de WhatsApp, que fracassaram ao adotar mensageria. O padrão se repete: não é a tecnologia que falha, é a falta de fundamento por trás das decisões técnicas que impactam negócio. Hoje vamos sair da implementação e falar do que vem antes dela: os conceitos essenciais de Event Driven Architecture e as decisões que parecem corretas no papel, mas sabotam o projeto em produção. O Oragon.RabbitMQ aparece como pano de fundo, mas o assunto é arquitetura — e vale para qualquer stack. Nosso compromisso: cada live tem que valer mais que curso pago sobre o assunto. Em troca, pedimos só presença e like. Te espero às 21h no Canal .NET no youtube. https://share.gago.io/-MqC

Estratégias de alocação em SaaS multi-tenant (maturidade nível 4) Em modelos SaaS que atingem o nível 4 de maturidade: multi-tenancy pleno, com instância única compartilhada e escalabilidade horizontal. A distribuição da alocação de tenants pode ser escolhida conforme a demanda e os objetivos do negócio. Há duas estratégias fundamentais, e elas expressam filosofias opostas de arquitetura: 1) Consolidação (bin packing): saturar um nó antes de abrir o próximo. Toda a capacidade de um nó é ocupada e, somente ao atingir seu limite, um segundo nó entra em cena. Nesse caso, privilegiamos densidade e, por consequência, eficiência econômica: máxima utilização de recursos, menor número de nós ativos, menor custo de infraestrutura e de licenciamento, possibilidade de desligar nós ociosos (scale-to-zero parcial). É a lógica do utilitarista: o maior aproveitamento pelo menor custo. 2) Espalhamento (spreading): distribuir os tenants por diversos nós desde o início. A carga é diluída horizontalmente, mantendo todos os nós com folga operacional. Nesse caso, privilegiamos resiliência e disponibilidade. O espalhamento reduz o blast radius: a falha de um nó afeta uma fração pequena dos tenants; há headroom para absorver picos súbitos de demanda sem cold start; e diminui-se o efeito noisy neighbor, pois tenants ruidosos ficam isolados por menor densidade de coabitação. — Nesse projeto optamos pela 2a opção, por se tratar de um projeto que já nasceu com mais de 3 mil clientes conectados.

Uma dica importante para quem quer fazer conta sobre escala, ou volume de operações. Em alguns tipos de sistema o volume crítico é condensado em uma janela de tempo que representa uma fração do dia. Quem já viu na mentoria as planilhas que levam em conta a hora do dia, vai lembrar. Esse é um gráfico de produção, real. Então projetar o workload como se fosse diluído ao longo do dia, gera inconsistência com a realidade. Fazer a conta com X operações por dia para deduzir Y operações por hora, geraria um número irreal. Saber que 50%, 75% até 90% do workload será realizado durante uma janela de pico, faz pensarmos em números mais realistas. Essa é uma lembrança de que esse entendimento importa.

Projetar para startups tem seus desafios, mas nascer grande é desafio que explora a experiência. Reestruturações demandam mais que conhecimento teórico, exige conhecimento de campo de batalha. De um lado havia um sistema, existe uma base de clientes, usuários munidos de esperança de um atendimento melhor. De outro um sistema novo, com uma arquitetura nova, desenhado para o próximo nível de escala, que geralmente carrega consigo muita expectativa e pouca margem para erro e aprendizado. Reestruturações me lembram uma frase de Natan Muir em Spy Game: "Então eu não tive o tempo normal para... . O que significa que precisávamos do dobro do sexo com metade das preliminares." Hoje é dia de comemorar! Mais um case entregue com sucesso. Mais um case cheios de desafios, cheio de empecilhos que mais pareciam sabotagem. Mas apesar de tudo isso, saiu e com sucesso. Mais de 300 instâncias de serviço. Mais de 20 nós Kubernetes na França Mais de 10 nós Docker no Brasil com quase 5 mil containers gerenciados dinamicamente pela aplicação RabbitMQ, Postgres com redundância em multi-AZ Mais de 30 mil conexões simultâneas no RabbitMQ, 73 exchanges, mais de 18 mil filas, 30 mil consumers, 12 shovels. 3 microsserviços. Vezes mais capacidade, vezes mais resiliência, vezes mais observabilidade, consumindo uma fração da infraestrutura original. Não foi "barato", custou 1 ano. Mas finalmente saiu mais um case cloud native. .NET + Go, Apisix, Dragonfly , Postgres, Vault, Kubernetes, RabbitMQ, docker. Event driven architecture + Microservices Em breve novidades em posts e conteúdo!

TypeScript 7 Is Here (And It's 10× Faster) Anders Hejlsberg, especialista técnico em TypeScript, apresenta o TypeScript 7, a versão para código nativo (Go) do compilador e das ferramentas que é cerca de 10 vezes mais rápida que o TypeScript 6. Veja uma compilação ao vivo do código-fonte de 2,3 milhões de linhas do VS Code, que passou de 50 segundos para menos de 5 segundos, observe como a concorrência em memória compartilhada utiliza todos os núcleos da CPU e confira o novo servidor de linguagem baseado em LSP com referências, rabiscos e inicialização quase instantâneos — tudo com 99,99% de compatibilidade com o TypeScript 6. https://www.youtube.com/watch?v=OytpXXeNmTQ

Nada me deixa mais puto do que errar previsível e errar no que eu disse que daria merda. É um atestado de incompetência na comunicação das previsões óbvias.

Ë muito comum pensar que exista alguma relação de paridade entre filas e tabelas. Ou que criar fila é tarefa de infra ou de manutenção da infraestrutura, assim como tabelas são. Sim, podem existir filas criadas para viabilizar a subida do sistema, mas aqui 100% delas são gerenciadas pela aplicação. A aplicação usa aproximadamente umas 70~100 filas (que acaba se tornando 140~200 se contarmos suas respectivas dlq's), todas as demais são filas criadas quando o cliente se cadastra. Nesse cliente Já temos 7 mil filas, onde cada cliente possui 2 filas (processamento e erro). Isso é importante para dar clareza sobre como usamos rabbitmq em aplicações reais longe do get started. PS: há um superdimensionnamento porque ainda não adicionei keda ao fluxo

Novidade Importante e relevante Agent Skills for .NET is now stable and ready for production. Uma skill (habilidade) pode combinar instruções, documentos de referência, roteiros e outros recursos. Os agentes descobrem e carregam apenas o que uma tarefa exige, ajudando a manter a janela de contexto focada enquanto tornam o conhecimento especializado reutilizável entre múltiplos agentes. As principais capacidades incluem: • Habilidades baseadas em arquivos, classes e definidas por código • Distribuição independente por meio de repositórios ou pacotes internos de NuGet Gallery • Aprovação humano-in-the-loop ativada por padrão • Controlava a execução de scripts e o sandboxing personalizado • Filtragem de habilidades, cache e isolamento multi-inquilino • Pipelines extensíveis para registros de habilidades personalizados Isso cria um caminho prático para transformar políticas da empresa, manuais de suporte, procedimentos de integração e fluxos de trabalho específicos de domínio em capacidades governadas e auditáveis para agentes. Publicação Original

Hoje recebi a confirmação da renovação do Microsoft MVP pelo 8º ano consecutivo! 💙 É uma conquista que me deixa muito feliz, não apenas pelo reconhecimento, mas pelo que ele representa. Ao longo deste último ciclo, continuei investindo naquilo em que acredito: Compartilhar conhecimento gratuitamente com a comunidade e criar as soluções e projetos que gostaria que a comunidade já tivesse criado. Apoiar diariamente desenvolvedores no @dotnetbr. Produzir conteúdo sobre arquitetura de software e .NET no https://share.gago.io/zHoD. Publicar e manter projetos Open Source, como o Oragon.RabbitMQ e Oragon.ElasticPool. Gravar episódios do DevShow Podcast. Ministrar cursos, mentorias, palestras e participar de eventos da comunidade. A maior parte de tudo o que produzo continua sendo gratuita, porque acredito que conhecimento acessível transforma carreiras. Meu objetivo sempre foi reduzir barreiras para quem já está no meio da jornada, mas precisa dar o próximo passo, apoiar profissionais que trabalham em ambie

Mais 1 semana de Fable 5

Novidade: Fable 5 prorrogado até dia 12

Houston... we are up!

Será que foi exagero bloquear Mythos e Fable 5? Em matéria de 14 de Junho, relata o motivo pelo qual o Mythos foi bloqueado no dia 12 do mesmo mês. Segundo o The Economist: Em 11 de junho, Mark Warner, vice-presidente do Comitê de Inteligência do Senado, afirmou que o General Joshua Rudd, chefe da Agência de Segurança Nacional e do Comando Cibernético do Pentágono, lhe disse que o Mythos "invadiu quase todos os nossos sistemas confidenciais, não em semanas, mas em horas". Matéria completa está em inglês aqui | https://www.economist.com/briefing/2026/06/14/donald-trumps-blocking-of-anthropic-is-capricious-and-chaotic