Categoria
Um sistema de permissões escalável precisa suportar milhões de usuários, bilhões de recursos e milhares de regras sem degradar a latência. A escalabilidade horizontal — adicionar mais servidores — é preferível à vertical (aumentar recursos de uma única máquina), pois permite crescimento elástico.
Em sistemas distribuídos modernos, a comunicação assíncrona via filas de mensagens (como RabbitMQ, Apache Kafka ou Amazon SQS) é essencial para desacoplar serviços. No entanto, um problema crítico surge quando precisamos garantir que uma mensagem seja publicada exatamente quando uma transação de banco de dados é confirmada.
A escalabilidade em produtos SaaS não é um luxo — é uma necessidade competitiva. Quando sua base de clientes cresce, o sistema precisa acomodar mais usuários, mais dados e mais requisições sem degradar a experiência.
O padrão bulkhead, também conhecido como compartimentação, tem sua origem na engenharia naval, onde navios são divididos em compartimentos estanques para evitar que uma avaria em uma área inunde todo o navio. No desenvolvimento de software, esse princípio é aplicado para isolar componentes de um sistema, garantindo que uma falha em um módulo não se propague para outros módulos.
O termo "poliglota persistente" foi cunhado por Neal Ford e Martin Fowler no início dos anos 2010 para descrever a prática de utilizar diferentes tecnologias de armazenamento de dados em uma mesma aplicação, cada uma escolhida para atender a requisitos específicos de um subdomínio. A ideia central é que nenhum banco de dados é universalmente ideal para todos os cenários; a diversidade de modelos de dados e padrões de acesso exige uma abordagem especializada.
Domain-Driven Design (DDD) é uma abordagem de desenvolvimento de software que coloca o domínio do negócio no centro do processo de design. Surgiu como resposta ao problema da complexidade acidental — aquela que criamos ao modelar soluções técnicas que não refletem fielmente a realidade do negócio — em oposição à complexidade essencial, que é inerente ao próprio domínio.
Transações distribuídas envolvem operações que afetam múltiplos bancos de dados, serviços ou sistemas de forma atômica. O protocolo two-phase commit (2PC) foi a abordagem clássica para garantir essa atomicidade: um coordenador pergunta a todos os participantes se podem confirmar (fase prepare) e, se todos responderem "sim", envia o comando de commit (fase commit). Na prática, porém, o 2PC é frágil porque depende de um coordenador central que se torna um ponto único de falha e de bloqueio.
A Clean Architecture, proposta por Robert C. Martin, estabelece que o código deve ser organizado em camadas concêntricas, onde as regras de negócio ficam no centro e dependências externas (frameworks, bancos de dados, interfaces) são mantidas nas bordas. Os princípios fundamentais são: independência de frameworks, testabilidade, separação em camadas e inversão de dependências.
Architecture Decision Records (ADRs) são documentos leves que capturam decisões arquiteturais importantes em um projeto de software. Cada ADR registra uma decisão específica, seu contexto, as alternativas consideradas e as consequências esperadas. O conceito foi formalizado por Michael Nygard em 2011, no artigo "Documenting Architecture Decisions", como uma resposta à necessidade de rastrear o "porquê" por trás das escolhas técnicas.
Backpressure é o mecanismo de controle de fluxo que permite que sistemas de alto throughput regulem a taxa de processamento entre produtores e consumidores. Em vez de permitir que um produtor sobrecarregue um consumidor, o backpressure sinaliza ao produtor que reduza sua taxa de envio ou pare temporariamente.