Architecture

Tag: architecture

• Someone says event, and magically, coupling goes away (16 February 2024)
  I feel events are used too many times as a hammer to dismantle coupling. Unfortunately, it's gold plating. It might look better, but it'll fire back in the long term and cost more.
• I gotta tell you: CQRS doesn't imply Event Sourcing (27 January 2024)
  Too many times, Event Sourcing is presented as the natural companion to CQRS. That's not the case. CQRS doesn't dictate using Event Sourcing. Let's see why.
• Compensation is all around us (28 November 2023)
  In a message-based system, we might feel a lack of control, especially when in need of compensating changes spread across the system. Fear not! Real life deals with compensation every day! And it's better than rolling back a transaction or deleting some data in the database.
• Append-only models: The why, the when, and the how (22 September 2023)
  There are scenarios where updating data is either forbidden by policies or undesirable because it hinders the ability to fulfill other requirements. That is when append-only models come to the rescue.
• What if my command was rejected? (27 June 2023)
  Distributed systems are different and require a different mindset. That's particularly true when dealing with async processes and failures. We need new tools and a new toolbox. And in the end, we can avoid rejecting that command.
• Back to Basics: commands, events, and messages (25 May 2023)
  When you're involved with something for a very long time, it's easy to fall into the trap of taking many concepts for granted. Let's go back to the basics and build a common foundation. Today's topics are commands, events, and messages.
• Back to Basics: service boundaries, autonomous components, and coupling (17 May 2023)
  When you're involved with something for a very long time, it's easy to fall into the trap of taking many concepts for granted. Let's go back to the basics and build a common foundation. Today's topics are service boundaries, autonomous components, and coupling.
• How many (micro)services do I need? (15 March 2023)
  Microservices, microservices everywhere. But how many of them do we need? It's easy to be trapped by the micro thing and end up with thousands of them. Let's try to provide some guidance.
• Know your limits. Infinite scalability doesn't exist (30 May 2022)
  There is this myth that we can design today for tomorrow's unknown requirements. Somehow we believe that we can put in place a robust architecture that will scale forever, no matter what. I'm sorry, that's impossible.
• Let's get logical! On logical and physical architectural views (25 January 2022)
  Having a deep understanding of the differences between physical and logical boundaries can help shed light on the way we architect systems. Usually, it leads to simpler solutions.
• You don't need that abstraction (20 December 2021)
  Abstractions, abstractions everywhere! We're obsessed with clean design and architecture. Do we need that, or does the introduced cognitive load come with more issues than benefits?
• Don't keep a saga in both camps (28 July 2021)
  When it comes to distributed systems, autonomy is a guiding star, and coupling is the villain trying to sneak in at every step. Orchestration is a particularly subtle form of coupling, usually detected when it's too late. However, the root cause is somewhere else.
• Own the cache! (15 July 2021)
  Caches are everywhere and power the internet. When it comes to distributed systems, they are an essential tool in our tool belt. However, special care needs to be put into defining who owns the cache.
• To API, or not to API. Is this a real problem? (24 March 2021)
  Breaking a public API is scary but sometimes unavoidable. Versioning an API is complex and error-prone. In many cases, I observed teams breaking an API that should not have been there to begin with, or fighting with versioning issues. The problem, though, was not the API.
• Not all changes are born equal (10 March 2021)
  We should not fear change. There are changes for good and changes for bad. As for change, we should not fear coupling. There is bad coupling and good coupling. The critical aspect is to understand the impact of the changes and the coupling.
• You don't have to be cool to rule my world, KISS. (8 May 2019)
  HTTP is the Microservices way, so it must be used as a communication transport, they say. Is HTTP adding any benefit to our systems? Can it be considered harmful in some scenarios? Are there better approaches? Shedding some light on the system logical architecture might be helpful.