E se todas as redes sociais fossem obrigadas a verificar informações?

Nunca foi tão fácil produzir e compartilhar conteúdo. Hoje, boa parte da população tem acesso à internet, um celular na mão e a possibilidade de publicar qualquer coisa para milhares ou até milhões de pessoas.

Isso é incrível. Nunca tivemos tanto acesso à informação, tantas possibilidades de aprender e tanta liberdade para compartilhar ideias.

Mas existe um outro lado dessa história.

Produzir conteúdo ficou fácil. Verificar se ele é verdadeiro continua dando trabalho.

Pensa em como funciona no dia a dia. Você recebe uma notícia no WhatsApp, vê uma publicação no Instagram ou encontra um vídeo no Facebook. O conteúdo confirma algo em que você já acredita, provoca indignação ou parece revelar uma informação que ninguém está contando.

Você compartilha.

Tudo isso pode acontecer em poucos segundos, sem abrir um link, procurar a fonte original ou conferir se aquela informação faz sentido.

E não é necessariamente porque as pessoas são ruins ou querem espalhar mentiras. Muitas vezes, é porque estamos acostumados a consumir conteúdo rapidamente. Verificar exige tempo, atenção e disposição para questionar algo que talvez a gente queira muito acreditar.

O problema é que compartilhar virou um reflexo, enquanto verificar ainda é um esforço.

Uma informação falsa pode alcançar milhares de pessoas antes que alguém tenha tempo de conferir os fatos. E, quando a correção chega, muitas vezes ela não alcança o mesmo público.

Quem compartilhou a informação original talvez nem fique sabendo que ela estava errada.

E assim, sem perceber, qualquer um de nós pode acabar virando um vetor de desinformação.

E se verificar fosse tão fácil quanto compartilhar?

Hoje, quando você encontra uma informação duvidosa, precisa parar o que está fazendo, pesquisar no Google, encontrar fontes confiáveis, comparar versões e tentar descobrir se alguém já verificou aquela afirmação.

É possível fazer tudo isso? Claro.

Mas vamos ser sinceros: quantas pessoas fazem esse processo antes de apertar o botão de compartilhar?

E se a gente mudasse essa lógica?

Imagine encontrar, ao lado de uma publicação, um pequeno indicador mostrando se aquela informação foi avaliada por profissionais qualificados. Um polegar verde para uma classificação de FATO, um vermelho para FAKE e um ícone para consultar as fontes e entender como a conclusão foi alcançada.

Sem precisar sair da rede social. Sem abrir cinco abas no navegador. Sem depender de descobrir sozinho quem já investigou aquele assunto.

Se ainda não houver informação suficiente para uma conclusão, o sistema simplesmente informa que a avaliação está em andamento.

A ideia é simples: aproximar a verificação do lugar onde a desinformação circula.

Não seria uma solução mágica, mas poderia tornar o acesso às evidências muito mais fácil.

Minha proposta: um sistema unificado de verificação de informações

Na minha visão, deveríamos discutir seriamente a criação de um sistema unificado de verificação de informações, estabelecido por lei e integrado às plataformas digitais.

Facebook, Instagram, X, TikTok, YouTube e outras redes participariam obrigatoriamente dessa infraestrutura.

A proposta não é criar mais uma rede social, nem obrigar as pessoas a usar um aplicativo específico. É construir um serviço compartilhado, capaz de disponibilizar avaliações e referências diretamente nas plataformas em que as informações são publicadas.

Pense em algo parecido com uma infraestrutura pública digital: um sistema comum, utilizado por diferentes empresas, com regras conhecidas e mecanismos de fiscalização.

Em vez de cada plataforma criar seu próprio processo isolado, teríamos uma estrutura que permitiria consultar avaliações já existentes e evitaria que o mesmo trabalho precisasse ser refeito várias vezes.

E como isso funcionaria?

O governo cuidaria das regras. Profissionais qualificados avaliariam.

Aqui existe um ponto importante: não estou propondo que o governo decida sozinho o que é verdade ou mentira.

Minha proposta é que ele seja responsável por garantir a existência e o funcionamento do sistema, estabelecer regras públicas, fiscalizar os processos e coordenar um modelo de credenciamento de profissionais qualificados.

A avaliação, por sua vez, seria realizada por pessoas com conhecimento adequado ao assunto analisado.

Uma afirmação sobre saúde pode exigir conhecimento médico ou científico. Uma alegação sobre economia pode precisar de especialistas em dados econômicos. Uma declaração política pode exigir a consulta a documentos oficiais, registros públicos e fontes verificáveis.

O importante é que ninguém receba autoridade para classificar informações simplesmente por ocupar determinado cargo ou defender uma posição política.

Os profissionais precisariam justificar suas avaliações, apresentar referências e seguir critérios transparentes.

Também seria necessário permitir contestações, auditorias independentes e revisões quando surgissem novas evidências.

O governo garantiria as regras do jogo, mas não poderia ser o dono da verdade.

Essa separação é essencial para que o sistema não se transforme em uma ferramenta de favorecimento político ou de perseguição a quem pensa diferente.

Como isso apareceria nas redes sociais?

A experiência para quem usa a rede seria extremamente simples.

Ao lado de uma publicação, apareceria um pequeno componente visual, discreto, sem atrapalhar curtidas, comentários ou compartilhamentos.

• Polegar verde: a informação foi classificada como FATO.
• Polegar vermelho: a informação foi classificada como FAKE.
• Ícone de notas: permite consultar as fontes, as justificativas e o estado da avaliação.

Os dois primeiros indicadores só apareceriam quando existisse uma classificação pública válida. Enquanto a avaliação estivesse em andamento ou houvesse empate, o usuário poderia consultar os detalhes sem receber um resultado prematuro.

Não seria necessário exibir percentuais ou transformar a verificação em uma disputa de popularidade. A ideia é mostrar a conclusão fundamentada e permitir que qualquer pessoa interessada consulte as evidências.

Para votar, o funcionamento seria diferente. Somente profissionais credenciados e autorizados poderiam participar da avaliação, apresentando uma justificativa e pelo menos uma referência verificável.

Uma classificação pública só seria liberada depois de atingir um número mínimo de avaliações válidas e apresentar uma maioria conforme as regras definidas.

E mesmo assim, a classificação não deveria ser tratada como infalível. Se surgissem novas evidências ou a avaliação deixasse de atender aos critérios, o resultado precisaria ser revisto.

O objetivo não é substituir o pensamento crítico por um ícone. É facilitar o primeiro passo para quem quer conferir uma informação.

Mas isso não seria censura?

Essa pergunta precisa ser levada a sério.

Um sistema centralizado de verificação pode ser útil, mas também pode ser perigoso se for mal projetado. Se uma instituição tiver poder para classificar qualquer opinião como falsa, teremos um problema muito maior do que aquele que tentamos resolver.

Por isso, os limites precisam estar claros desde o início.

Uma opinião não é a mesma coisa que uma afirmação factual.

Você pode defender um candidato, discordar de uma política pública, criticar uma instituição ou acreditar que determinada decisão foi um erro. Nada disso deveria ser classificado como falso simplesmente porque alguém discorda de você.

O sistema deve se concentrar em afirmações que possam ser confrontadas com evidências: dados apresentados como reais, acontecimentos alegados, declarações atribuídas a alguém, resultados de pesquisas e outras informações verificáveis.

Quando não houver evidências suficientes, deve reconhecer a incerteza. Quando houver divergências legítimas, deve permitir que elas sejam conhecidas. Quando errar, deve corrigir.

E o processo inteiro precisa ser transparente, auditável e sujeito a fiscalização independente.

A proposta não é impedir alguém de publicar uma informação. É oferecer condições melhores para que as pessoas avaliem aquilo que estão consumindo.

E se os próprios especialistas discordarem?

Isso vai acontecer. E não há problema em reconhecer isso.

Nem toda questão tem uma resposta simples. Algumas dependem do contexto, outras envolvem evidências incompletas e outras podem mudar com o avanço do conhecimento.

Por isso, o sistema precisa admitir que nem sempre será possível chegar a uma conclusão.

Um empate não deveria ser resolvido artificialmente. Uma publicação sem evidências suficientes não deveria receber um selo definitivo. E uma avaliação antiga não deveria continuar sendo tratada como atual quando novas descobertas mudassem o cenário.

Também seria importante registrar as justificativas, manter o histórico das revisões e permitir que outras pessoas apresentassem evidências relevantes.

O número de profissionais envolvidos importa, mas não substitui a qualidade das fontes e dos argumentos.

A confiança viria da possibilidade de entender como a conclusão foi alcançada, e não apenas de acreditar em quem colocou o selo.

Por que isso deveria ser obrigatório por lei?

Porque a desinformação não fica dentro dos limites de uma única empresa.

Uma publicação pode começar no Facebook, ser reproduzida no Instagram, virar um vídeo no TikTok e chegar a grupos de mensagens em poucas horas.

Se cada plataforma trabalhar de forma isolada, teremos processos diferentes, avaliações duplicadas e resultados difíceis de consultar.

Uma infraestrutura comum poderia permitir que uma avaliação fosse aproveitada por diferentes plataformas, respeitando o contexto e a identidade de cada publicação.

A obrigação legal também evitaria que a participação dependesse apenas da vontade comercial das empresas.

É claro que essa obrigação precisaria ser proporcional e tecnicamente viável. Não faria sentido monitorar indiscriminadamente conversas privadas ou enviar todo o conteúdo de todos os usuários para uma base centralizada.

O sistema deveria priorizar publicações públicas e conteúdos submetidos à verificação, respeitando a privacidade e a legislação aplicável.

A lei estabeleceria a participação obrigatória na infraestrutura, mas precisaria proteger a liberdade de expressão e impedir que o sistema fosse usado como ferramenta de vigilância.

O maior desafio não é construir a tecnologia

Do ponto de vista técnico, é possível construir APIs, bancos de dados, mecanismos de votação e extensões que mostrem os resultados diretamente nas redes sociais.

O desafio mais difícil é garantir que o sistema seja confiável.

Quem credencia os profissionais? Como evitar conflitos de interesse? Como impedir que um grupo político capture a estrutura? Como financiar o serviço sem comprometer sua independência? Como contestar uma avaliação injusta?

Essas perguntas não podem ficar para depois.

Uma possível saída seria criar uma governança independente, com participação de universidades, instituições de pesquisa, entidades profissionais, organizações da sociedade civil e especialistas em tecnologia, direito e proteção de dados.

As regras de avaliação seriam públicas. Os resultados poderiam ser auditados. As decisões poderiam ser contestadas. E o sistema publicaria relatórios sobre erros, revisões e seu próprio funcionamento.

Não existe uma estrutura perfeita, mas existem formas de reduzir riscos e impedir que o poder fique concentrado em uma única instituição.

A confiança não viria do fato de o sistema ser oficial. Viria da transparência e da possibilidade de fiscalizá-lo.

Não vamos acabar com a desinformação. Mas podemos mudar o jogo.

É importante ter expectativas realistas.

Um sistema como esse não acabaria com as notícias falsas, não convenceria todo mundo a mudar de opinião e não impediria que pessoas compartilhassem conteúdos sem verificar.

Mas poderia diminuir o esforço necessário para consultar evidências, facilitar o acesso a fontes confiáveis e tornar mais visível quando uma afirmação já foi avaliada.

E existe uma diferença enorme entre exigir que cada pessoa investigue tudo sozinha e oferecer uma infraestrutura que facilite esse trabalho.

Hoje, compartilhar é fácil e verificar é trabalhoso.

Minha proposta é aproximar essas duas coisas, usando a própria tecnologia que acelera a circulação de informações para facilitar também sua verificação.

Não precisamos concordar com todas as avaliações. Precisamos ter acesso às fontes, entender os critérios e contar com mecanismos para questionar decisões quando necessário.

Se as plataformas conseguem distribuir uma informação para milhões de pessoas em segundos, por que não deveriam também facilitar o acesso à verificação dessa informação?

Acredito que essa discussão merece sair das conversas informais e chegar à sociedade, às universidades, às empresas de tecnologia e ao poder público.

Não para criar um ministério da verdade, mas para construir uma infraestrutura que ajude as pessoas a distinguir afirmações sustentadas por evidências daquelas que não são.

Porque, no fim das contas, a internet nos deu uma capacidade enorme de compartilhar informações.

Talvez esteja na hora de tornar a verificação tão acessível quanto o compartilhamento.

O que você acha dessa proposta? Um sistema unificado, com profissionais qualificados, regras transparentes e participação obrigatória das plataformas, ajudaria a combater a desinformação ou criaria riscos maiores para a liberdade de expressão?

Tirando a ideia do papel

Estou trabalhando em um protótipo dessa ideia e quero explorar como tornar a verificação de informações mais simples e acessível no dia a dia. Ainda há muito a amadurecer, mas acredito que vale a pena dar o primeiro passo. E você, acha que um sistema assim ajudaria a combater a desinformação?

Star Catcher: transformando tarefas em estrelas ⭐

Combinar tarefas e recompensas com os filhos é fácil. Difícil é lembrar do combinado, acompanhar o que foi feito e evitar aquelas discussões sobre quem fez o quê. Foi para resolver esse problema que criei o Star Catcher, um aplicativo que transforma boas atitudes em estrelas que a criança pode juntar para conquistar seus próprios objetivos.

No Star Catcher, os pais definem quais comportamentos valem estrelas, aprovam as missões realizadas e acompanham o progresso. A criança tem seu próprio aplicativo, sem dinheiro ou preços na tela, e consegue visualizar suas estrelas, objetivos e conquistas. É uma forma simples de tornar os combinados mais claros e motivadores para toda a família.

👉 Quer conhecer o aplicativo e ver como funciona?
Acesse a página do Star Catcher e saiba mais: Conheça o Star Catcher

REST is No Longer Enough: Why Your APIs Need “Context” in the AI Era

The evolution of APIs seems to have plateaued in recent years. While Artificial Intelligence tools and autonomous agents evolve at an absurd speed, the way our APIs deliver data remains rigid and stuck in the past.

If you work in development, you’ve probably realized: we are trying to connect machines to systems that still rely on manuals made for humans. And that’s where the problem begins.

The Bottleneck: APIs Built for Humans, Used by Agents

When we create a traditional API, we design everything expecting a human to be in control. We assume the developer on the other side will read the documentation, understand the system’s nuances, and have the common sense to respect limits to avoid breaking anything.

The problem is that LLMs (Large Language Models) lack this intuition. They are literal. If you give an endpoint to an AI agent and ask for a bulk task, it will execute it as fast and as crudely as possible, unaware that this “bombardment” of requests could crash your server due to a lack of clear guidance on expected behavior.

The Danger of Missing Context: The “Killer” Script

Imagine the following scenario: you ask an AI to read 1,000 objects from an API and clone that data to another endpoint. It’s a trivial task.

• Without context: The AI generates a simple for loop and fires off 1,000 requests in milliseconds.
• The result: For many systems, this is an involuntary DoS attack. The AI delivered exactly what you asked for, but the system crashed because it didn’t know it needed to “throttle down.”

The Idea: The CONTEXT method

Inspired by the OPTIONS method (which browsers already use to understand permissions), why not create a standard specifically for AI agents? The idea is to explore a concept for a method called CONTEXT.

The flow would work like this: before an agent performs any GET, POST, or DELETE, it would do a quick query to the endpoint using this “context” method.

How this changes the game in practice

When querying this metadata, the API would return a JSON with the system’s “etiquette rules.” Example:

JSON

{
  "endpoint": "/v1/clone-objects",
  "rules": {
    "rate_limit_advice": "Never make more than 5 requests per second",
    "criticality": "high",
    "side_effects": "This command generates heavy load on the database"
  }
}

With this information in hand, the AI changes its behavior instantly. Instead of an aggressive script, it generates code with a sleep (pause) between calls, respecting the infrastructure’s health without you having to explicitly state this in the initial prompt.

The Future is Standardizing Context

We need to stop creating external scripts and “workarounds” to try and control AIs. Ideally, APIs should provide the necessary context for agents to work safely in a standardized and natural way.

Providing context should be the standard, not the exception. Just as we check for CORS permissions, we should check an API’s “expected behavior” before any interaction.

---

Want to see the full explanation and how this idea was tested in practice? Watch the video (in Portuguese):REST Não Basta Mais: O Problema do Contexto nas APIs

---

What do you think of this approach? Do you believe a metadata standard for agents would make integrations safer, or do you prefer to control everything via prompting?

Cursor | AI-Infused SDLC — Enhancing Software Development with Artificial Intelligence

Hello everyone! Hope you’re doing well.

Recently, the first Cursor community Meetup took place in Rio de Janeiro, hosted by Bemobi, and I had the pleasure of attending. This content only exists thanks to the collaboration of the team and the constant encouragement from our TM to explore new approaches. I decided to turn my presentation into a blog post to share how we are using Cursor in our daily work and the strategy we are adopting.

The Software Development Life Cycle (SDLC) is the backbone of any technology project. However, for decades, we have followed its phases manually and often in a disconnected way. But what if we could infuse each stage with artificial intelligence, transforming AI from a point solution into a true strategic partner?

In this article, I will show how an “AI-Infused SDLC” approach, using the Cursor IDE, can change the way we plan, design, and build software.

The Core Tool: Cursor and Its “Rules”

Before diving into the SDLC phases, it is essential to understand the central component of this approach: the Cursor IDE. Cursor is a code editor specifically designed to work with AI. Its main strength lies in the ability to inject precise context through “Cursor Rules.”

Cursor Rules act as a structured contextual memory for the AI model.

We started with a simple setup: a single rule for the project. However, it quickly became clear that it was difficult to explicitly express what the rule was doing and how we could scale this approach across different projects. To address this, we decided to organize our rules into hierarchical layers:

– Team-wide generic rules: file standards, development best practices, and methodological approaches.
– Project-specific rules: technology stack, code patterns, and internal conventions.
– Organizational information: communication channels, tools in use, and established processes.
– Business rules: domain-specific requirements, such as settlement rules or custom validations.
– System architecture: physical and semantic organization of the project.

The result is a rich context that allows the AI to generate PRDs, implementations, and documentation fully aligned with the project—transparently for the user who is writing the prompt.

Phase 1: Planning — Intelligent Planning

Planning is the initial phase where objectives, scope, and feasibility are defined. With Cursor, this stage gains a deeper analytical dimension through intelligent information processing.

AI can consolidate data from multiple sources to support strategic decisions:

– Market analysis: processing research documents and trend reports
– Technical evaluation: reviewing similar architectures and available technologies
– Effort estimation: based on historical projects and identified complexity
– Documentation from related projects

The outcome is a well-grounded project roadmap that serves as a solid foundation for the next phases.

Phase 2: Intelligent Requirements Analysis

Requirements analysis is traditionally one of the most critical phases of the SDLC, where clarity directly impacts project success. A key differentiator of this approach is that the IDE operator does not necessarily need to be a developer. With Cursor and well-defined contextual rules, a Product Owner can effectively lead this phase.

By using the Model Context Protocol (MCP), the AI gains authorized access to multiple knowledge sources, building a deep and multidimensional understanding of the problem.

Practical scenario led by a Product Owner:

– Code analysis: the AI scans the repository to map the current architecture, identify existing patterns, and highlight potential impact points.
– Database inspection: schemas and data are analyzed to understand how a new feature will affect the existing structure.
– Document review: meeting transcripts, technical specifications, and design documents are processed to extract key requirements.

The final output is a detailed task automatically created in Jira, including a technical summary, impact analysis, and preliminary acceptance criteria—all without disrupting the developers’ workflow.

Phase 3: Collaborative Design and Prototyping

With the initial task structured, we move into the Design phase. This is where we resist the temptation to “jump straight into coding” and instead focus on refining the solution. At this stage, the development team takes the lead, using AI as a brainstorming and prototyping partner.

The main objective is to create a detailed development plan, often materialized as a task list within the repository itself. This artifact acts as a critical bridge between business needs and an executable technical roadmap.

Iterative refinement of the task list with Cursor support:

– Generating code examples to illustrate proposed approaches (e.g., “For the new endpoint, we could follow this DTO pattern”)
– Suggesting function structures (e.g., “The interest calculation logic can be encapsulated in a dedicated function”)
– Proposing architectural patterns suitable for the project context

Important: all generated examples are added to the task list as guidance only. No production code is modified at this stage. This is a moment for strategic planning and expectation alignment.

This phase is essential because the task list breaks the delivery into smaller, manageable pieces and ensures that the plan is structured so that anyone can pick up the work at any point.

Phase 4: Strategic Coding — Controlled Scaling

With a clear technical roadmap, we move into the coding phase following a “controlled scaling” philosophy: progressing step by step, task by task, with continuous validation. This replaces chaotic execution with a safe, methodical process. It is no longer about writing a context-less prompt and expecting the AI to solve everything.

Each task is executed with full context awareness, leveraging all previously generated artifacts.

Article Scope

This article focuses on the first four phases of the SDLC: Planning, Analysis, Design, and Coding. The remaining stages—Testing, Deployment, and Maintenance—can also be significantly transformed by AI, but they will be covered in future articles.

Note that prompt engineering is not the main focus here, but those interested in going deeper can explore it separately.

Challenges and Key Considerations

Adopting AI in the SDLC is not without challenges:

– Context rot: excessive tokens can degrade model accuracy. Being selective about what context is provided is essential.
– Overreliance: AI-generated code must always undergo rigorous human review. Undetected errors can cause serious production issues. AI is a powerful partner, never a flawless replacement.
– Redundant documentation: AI may generate excessive or disorganized documentation. Curation processes are required to keep content relevant and up to date.

The core mantra: be patient and meticulous. Every output must be reviewed with technical rigor.

Lessons Learned

Even in an experimental phase, several insights have already emerged:

– Developer leveling: less experienced engineers gain confidence by using AI as an always-available senior pair programmer.
– Acceleration for seniors: senior developers significantly speed up repetitive tasks, freeing time for architectural challenges and strategic decisions. However, due to initial distrust, they often validate context independently before fully embracing AI suggestions.
– Input quality is critical: all provided context matters. Team discussions, architectural decisions, and business rules must be carefully documented and accessible to maximize AI effectiveness.

Conclusion: Toward an Intelligent SDLC

An AI-infused SDLC, especially when supported by tools like Cursor IDE, represents a natural evolution of software development. It is not about replacing human expertise, but about exponentially amplifying it.

What has been your experience with AI in software development? Share in the comments how you have been using tools like Cursor in your projects.

Living Architecture: Shaping Systems for Change

Every now and then, I find myself discussing software architecture with peers. While I’ve jotted down some ideas here and there, I’ve always felt there was one perspective missing—a view that goes beyond the buzzwords of clean architecture, ports and adapters, and DDD. Or maybe, on second thought, it fits right between these approaches, as they all draw from similar principles.

Ultimately, this may not be groundbreaking. But perhaps it’s something that your “zero to hero” course didn’t cover. So, I decided to leave another piece of the puzzle here—this ever-evolving enigma we call software architecture.

Domain

In the context of Domain-Driven Design (DDD), the domain is, essentially, the core of the system. It’s the area of focus or the problem the software was created to solve. Think of the domain as the part of the real world that the software models and interacts with.

It sounds simple, right? And it’s a concept you’ll encounter in many books and articles. But in practice, applying this idea is far from… linear.

Between Books and Real-World Chaos

One of the most iconic images of DDD is a clean separation of subdomains, each managed by distinct teams and systems. For example:

• Team A: Responsible for Optimal Acquisition, Purchasing, Inventory, and Resource Planning.

In an ideal world, everything would be neatly organized, running like clockwork, with perfect synergy between teams and subdomains.

But let’s add a pinch of reality. Imagine that, in the second week of the project, the company realizes Team A is overwhelmed. They restructure:

• Team B: Takes over Purchasing.
• Team C: Handles Resource Planning.

Weeks later, someone from Team C leaves, forcing them to merge with Team B, creating Team BC. To complicate things further, Team A transfers part of Inventory management to Team BC.

Now, the question is: Could your systems handle these team changes without breaking down? Does the way you build software allow you to reorganize components quickly and efficiently?

What I See Around Me

While the classic “models”, “views”, and “controllers” folder structure is becoming outdated, many projects still follow similar patterns—just with different folder names. For example, a single “infrastructure” folder crammed with everything.

Even though popular literature on DDD and clean architecture isn’t prescriptive about folder organization, I still see developers attempting to replicate these structures blindly, without considering whether they make sense for their project.

The System Isn’t Yours Alone (or Even Your Team’s)

Change is inevitable. Keeping this in mind, I prefer building systems based on modules—cohesive units with low coupling, designed to be easy to move or even delete if needed.

To achieve this, it’s crucial to understand that much of the infrastructure code must align with the domain’s needs. This close relationship makes it logical to treat infrastructure and domain as a unified logical unit.

But beyond infrastructure and domain, there’s another crucial component in my system design: libraries (or libs, cross cutting libs).

The Role of Libs

Libs are standalone components—they don’t depend on the domain. This makes them reusable across projects, enhancing modularity and sustainability in the long run.

Here’s a basic representation of the structure:

However, unlike infrastructure, libs don’t submit to the domain. They’re fully independent, allowing reuse in any project:

In larger systems with multiple modules, the structure evolves further:

The Golden Rule: No Direct Sharing

Nothing is shared directly between modules—only through the lib layer (or by messaging). This ensures the system remains modular and avoids the complexity of tangled dependencies.

Why This Approach?

This structure ensures:

• Flexibility: Components can be easily moved or repurposed.
• Reusability: Libs can be used in multiple projects, saving effort.
• Isolation: Problems in one module won’t directly affect others.

This mindset helps build systems that adapt to organizational changes while avoiding technical debt snowballs.

Conclusion

I didn’t share much code here, but I tried to convey how the approaches we choose for structuring systems are more than just technical decisions—they shape, and are shaped by, our day-to-day work.

Every design decision, from module organization to lib reuse, influences the challenges and opportunities we face in a project. Viewing architecture as a living entity that evolves with your team and business needs is the key to building sustainable, adaptable systems.

I hope this reflection encourages you to evaluate your architectural choices with a practical and strategic mindset. After all, software architecture is less about diagrams and more about creating a foundation that supports growth without chaos. 🚀

Banco de ideias

Sempre tive alguns cadernos de ideias que nunca saíram do papel , agora, já sem os cadernos, resolvi criar uma pagina aqui pra ir retroalimentando com essas ideias. Aqui deixarei somente os gatilhos, mas que provavelmente existe um doc mais elaborado para a ideia. Quem sabe um dia, um dia…não me animo a tirar do papel.

[ libs ]

[ 2023-11 ] [ golang ] Lib capaz de mover CSV para banco de dados garantindo a integridade dos dados

[ tools ]

[ 2021-01 ] Ferramenta para permitir teste sintético complexo por meio de uma interface

[ 2022-01 ] Ferramenta para padronização do postmortem

[ games ]

[ 2021-01 ] jogo que simula a gestão de um parque de sistemas na nuvem com o foco em engenharia de confiabilidade

[ 2016-01 ] Jogo de plataforma focado em divulgar e ensinar Libras

[ 2015-01 ] Jogo para testar os conhecimentos trabalhados nas escolas com perguntas simples e de resposta rápida.

[ 2015-01 ] Battle royale de nave visão lateral, onde o objetivo é pegar a coroa e tentar ficar o maior tempo possível em sua posse

[ 2018-01 ] Jogo online de time para “guerra na corda”

[ 2018-01 ] Jogo baseado em pokémon para ensinar o matemática e português

[ wearable ]

[ 2010-01 ] Gadget para dar mais autonomia para portadores de deficiência visual em ambientes com pouca rede disponível, como no metro.

[2018-01] Gadget focado em identificar padrões simples, como número do ônibus.   

Alertas bem elaborados

Alertar é o que nos notifica quando um problema surge ou está prestes a surgir, para que a ação possa ser tomada.

Criar alertas oportunos e significativos não são fáceis, mas são necessários, já que as pessoas tendem a ignorar os alertas quando sentem que não são precisos .

Alertas são problemas

Primeiro, alertas que requerem a atenção de um humano, muitas vezes conhecido como Pages, ou também aqueles alertas que vão acordar alguem de madrugada ou tirar a atenção de alguem durante o dia devem ser urgentes, importantes, passiveis de ação e reais. O problema de ter o over-monitoring ou mais alertas do que podemos controlar significa que que os analistas responsaveis vão parar de dar atenção para os alertas, ignorar eles quando acontecerem.

Um resumo é que um alerta tem que representar um PROBLEMA, e esse problema deve ter uma ação relacionada a ele. As ações podem ser conduzir uma investigação, alguma ação como remover um servidor defeituoso do balanceamento, criar uma ação de bugfix, ou até mesmo disparar uma ação de capacity planning.

Alertas bem elaborados

• Precisão :
  • Basicamente é a taxa de verdadeiro positivo
  • 100% de precisão significa que cada alerta corresponde a um evento significativo.
• Recall :
  • 100% de recall significa que todo evento significativo gerou um alerta.Ou seja, com isso não temos eventos significativos acontecendo que não estamos alarmando.
  • Ele é a proporção de eventos significativos que são detectados e transformados em alertas. 
• Tempo de detecção :
  • Quanto tempo leva para uma condição ser detectada e transformada em alertas
• Tempo de reinicialização :
  • Quanto tempo leva para que os alertas parem de disparar depois que a condição raiz for resolvida.
• Alertas baseados em sintomas
  • Seus usuários se importam se seus servidores MySQL está com alto consumo de CPU? Não, eles se importam se suas consultas estão demorando
  • Seus usuários se importam se um binário de suporte (ou seja, caminho sem serviço) está em um loop de reinicialização? Não, eles se importam se seus recursos estão falhando.
  • Os usuários, em geral, se preocupam com um pequeno número de coisas:
    • Disponibilidade e correção básicas. sem “Oops!”, sem 500s, sem solicitações travadas ou páginas carregadas pela metade ou Javascript ou CSS ausentes ou imagens ou vídeos. Qualquer coisa que interrompa o serviço principal de alguma forma deve ser considerada indisponibilidade.
    • Latência. Rápido, mas somente o suficiente.
    • Completude/frescura/durabilidade. Os dados de seus usuários devem estar seguros, devem retornar quando você solicitar e os índices de pesquisa devem estar atualizados. Mesmo que esteja temporariamente indisponível, os usuários devem ter total fé de que ele voltará.
    • Features. Seus usuários se preocupam que todos os recursos do serviço funcionem – você deve monitorar qualquer coisa que seja um aspecto importante do seu serviço, mesmo que não seja a funcionalidade/disponibilidade principal
• Runbooks
  • Importante que os alertas tenham playbooks ou runbooks, com informações sobre o que fazer, diagramas, informações sobre logs, dashboards etc. Devemos desenvolver sistemas como se quando eles derem problema seremos acordados a noite, e para evitar o esforço cognitivo de quem esta acabando de acordar eles devem conter bons runbooks, com os problemas conhecidos e melhores praticas de throbleshotting.
• Rastreaveis
  • Os alertas precisam ser rastreáveis. Precisamos conseguir chegar facilmente na fonte do alerta.

[SRE] Usando Multiwindow, Multi-Burn-Rate Alerts

Alerta	Janela longa	Janela curta	Duração	Taxa de queima	Orçamento consumido
P1	1h	5m	2m	14.4	2%
P2	6h	30m	15m	6	5%
P3	24h (1d)	2h	1h	3	10%
P4	32h (3d)	6h	3h	1	10%

No contexto tecnológico atual, a implementação de alertas multiwindow e multi-burn-rate representa uma abordagem inovadora para o monitoramento eficiente de sistemas. A capacidade de visualizar simultaneamente várias interfaces, combinada com alertas sensíveis a diferentes intensidades operacionais, oferece uma visão abrangente e em tempo real das operações críticas. Essa integração não apenas melhora a capacidade de resposta a eventos urgentes, mas também permite uma alocação eficiente de recursos, destacando-se como uma solução valiosa para ambientes empresariais que demandam agilidade e adaptabilidade na gestão de sistemas complexos.

Usando Multiwindow, Multi-Burn-Rate Alerts do cap 5 – Alerting on SLOs com as considerações do Björn “Beorn” Rabenstein

Tabela com 30 dias de janela

• Alerta
  • Os alarmes podem ter sua criticidade mais elevada (P1) ou podem ser apenas avisos de algo que não anda bem (P4)
  • Janela longa e Janela curta
    • AS janelas de queima múltipla servem para notificar apenas quando ainda estivermos queimando ativamente o orçamento
    • Uma boa diretriz é fazer com que a janela curta tenha 1/12 da duração da janela longa.
      
• Duração
  • Um tempo arbitrário, que normalmente é a metade da janela curta, pra evitar que um alarme fique sendo acionado com frequência.
    Um tempo arbitrário, que normalmente é a metade da janela curta, pra evitar que um alarme fique sendo acionado com frequência.
    
• Taxa de queima
  • formula: burn rate = budget consumed x period / alert window
    Exemplo:
    budget consumed = 2%
    period = 30 dias = 30*24 = 720
    alert window = 1h (janela de longa duração)
    burn rate = 0.02 * 720 / 1 = 14.4
  • A taxa de erro média é exatamente o fator 1, a taxa de erro que você poderia sustentar sem estourar seu orçamento de erro
  • Com o orçamento de erro de 0,1% (SLO 99.9%), se sua taxa de queima for 14,4% em média ao longo de uma hora (janela lonja), você obtém um alerta P1, e no momento em que a obtém , você queimou 2% do seu orçamento mensal de erros, em apenas uma hora! Isso é muito rápido. É aqui que alguém tem que acordar e consertar.
    
• Orçamento consumido
  • Orçamento consumido na janela prevista. De acordo com a tabela, em 3d com taxa de queima 1 iremos consumir 10% do orçamento

Princípios da jornada de SRE

O que faz um SRE? 

A principal característica de um sistema deve ser a confiabilidade. O foco do SRE está na confiabilidade do sistema. O papel do SRE, de uma forma bem alto nível são somente dois: Medir e Garantir. E para isso existe uma série de princípios que devem ser compreendidos. Além de auxiliar no ciclo de vida do produto.

Principios para SRE

• Aceitando os riscos
• SLx
• Eliminando Toil
• Monitoração
• Automação
• Engenharia de Release
• Simplicidade
• Design de Sistema (Grandes) Não Abstrato (NALSD)

Aceitando os riscos

Aceitar o risco significa estabelecer um nível aceitável de confiabilidade, que pese os custos do que está sendo assumido em relação ao risco. E para aceitar o risco a filosofia de usar error budget precisa estar bem establecida para que funcione.

Níveis de serviço

 Coração da engenharia de confiabilidade, os SLO`s, SLI`s e SLA`s e Error Budgets. o SLA, a promessa feita para o cliente, é o mínimo disposto em contrato, os SLO`s são os objetivos que você quer atingir além desse contrato, e os SLI são os indicadores que você vai utilizar pra acompanhar como estão o andamento desses objetivos.

Eliminando Toil

Reduzir as tarefas repetitivas para gastar energia em coisas urgentes com automação e um meta importante para o SRE. Simplesmente se estamos querendo reduzir nosso TOIL precisamos automatizar coisas, mas com o devido planejamento porque algo automatizado erradamente gera ainda mais pŕobelamas. O objetivo de qualificar algo como TOIL justamente indica para onde o esforço com automação deve ir, ou seja, problemas no fluxo de valor não devem ser, a priori, qualificados como TOIL.

Monitoração

Como dito anteriormente, medir e garantir. Todas as decisões tomadas devem estar pautadas em números, ou seja, certifique-se de que seu serviço produz as métricas de que você precisa. Alguns padores como 4 golden signals, RED E LEV podem fornecer o template inicial para algumas métricas.

Automação

Automatize tudo que possa ser automatizado, mas certifique-se de garantir, como qualquer outro código, a qualidade/confiabilidade por meio de testes.

Engenharia de Release

Tenha padrões de lançamento. Monitore as estatísticas sobre seus lançamentos. Entenda bem como continuous integration (CI), continuous delivery(CD) e continuous deployment (CD) funcionam de verdade.

Simplicidade

Sistemas simples tendem a ser confiáveis ​​e fáceis de operar, porem, medir a complexidade dos sistemas não será uma tarefa fácil. Saber com quanto tempo alguém leva para fazer mudanças, ou o tempo que alguém leva pra ter uma visão abrangente de alto nível do serviço pode ajudar.

Design de Sistema (Grandes) Não Abstrato (NALSD)

Com responsabilidades que abrangem as operações de produção e engenharia de produto, a SRE está em uma posição única para alinhar os requisitos do business case e os custos operacionais. As equipes de engenharia de produto podem não estar cientes do custo de manutenção dos sistemas que projetam. Pratique a capacidade de aferir, projetar e avaliar (grandes) sistemas, não deixe nada “abstrato” antes de implementar algo. Deixar de construir um plano de falha para alguma ponta solta pode custar caro, isso não significa implementar, mas sim que evite ser pego de surpresa se algo falhar. Na fase de concepção use perguntas como:

• É possível?
• Isso é viável?
• É resiliente?
• Podemos fazer melhor?

Desta forma estaremos mais perto de construir sistemas saudáveis e duradouros.

[SRE] Por sistemas mais LEV

Este vai ser um post rápido! 😉 
Estou em uma jornada de confiabilidade (SRE) e aprendendo muito. Uma dificuldade inicial tem sido a evangelização das práticas, e, principalmente, a definição de SLO. Pensando nisso, e muito inspirado no VALET da The Home Depot’s, estamos indo em direção ao LEV (Latency, Errors e Volume), onde temos algumas perguntas para ajudar os devs/produto a construir os seus SLO, segue alguns exemplos:

Latency

• O serviço responde rapidamente quando eu o uso?
  •  Quão rápido meu serviço tem que ser?
  •  O que faremos se o serviço estiver demorando mais que o esperado?

Errors

• O serviço gera um erro quando eu o uso?
  • O que faremos se o serviço estiver com mais erro que o esperado?

Volume (traffic)

• Quanto volume de negócios meu serviço pode suportar?
  •  O que faremos se o volume for maior (ou muito menor) que o esperado?

[ update 2023-11 ]

O termo “Let Go” tem parecido mais promissor, já que, para ir para produção (Go) tem que ter o Let (Latency-Errors-Traffic) definido.