All posts
-
Seeing Beyond the Boxes and Arrows
Two recent design discussions at work left me reflecting on a handful of recurring patterns that can prevent architecture conversations from moving forward. In…
-
Architecting for Change - Part V: Why Architecture Review Boards Make Complexity Worse
In the previous post in this series, I looked at accidental complexity and how it enters a system. When organisations begin to feel the effects of accidental…
-
Microservices Did Not Fail. The Boundaries Did.
This post comes off the back of a week of seeing the same old “microservices are bad, monoliths are good” arguments. In some contexts, that reaction is…
-
Architecting for Change Part IV: How Accidental Complexity Gets Into a System
Accidental complexity rarely announces itself. It usually arrives as drag. Changes that should be straightforward take longer than expected. Teams need more…
-
EventSourcing
Lessons from the Trenches: CQRS, Event Sourcing, and the Cost of Tooling Constraints
Several years ago, I led the implementation of a set of CQRS-based, event-sourced microservices built using Domain-Driven Design (DDD) for a bank. From the…
-
Architecting for Change - Part III: Sources of Complexity
In my previous post, I examined how complexity and cognitive load can hinder delivery, compromise security, and make systems more difficult to evolve and…
-
Architecting for Change - Part II: Complexity & Cognitive Load's Impact
The last post in this series discussed the implications of not architecting for change. I highlighted several issues that ultimately increase the cost of…
-
DDD Misconceptions
I have seen numerous implementations of DDD over the years, and during that time, I have noticed a few recurring misconceptions. Addressing these misconceptions…
-
OpenTelemetry
Understanding the True Causes of High Logging Costs
In my previous blog post, I spoke about the evolution of observability, exploring its history and the rise of OpenTelemetry as a powerful tool to tackle modern…
-
Architecting for Change - Part I: Why Does It Matter?
There are myriad reasons for change. Competition, evolving user expectations, technological advancements, regulations, bugs, security fixes, performance…
-
The Hidden Complexity of CRUD
In an age where microservices have become the architectural norm, it’s common to see service interfaces defined as simple CRUD endpoints. At first glance, this…
-
The Evolution of Observability
Observability's origin story starts in control theory. Control theory is a field of engineering and mathematics that deals with understanding and influencing…
-
Architecture
Evaluating an Asynchronous Processing Design
I was recently asked to provide feedback on an implementation designed to decouple accepting requests in a service from processing them. Initially, I intended…
-
Targeted Event-Carried State Transfer
Another flavour of microservices’ integration
-
-
-
Read Models Spanning Microservices’ Boundaries
Or glorified data caches
-
Event Sourcing — Oops, wrong Aggregate Boundary
How I shared streams to split an aggregate and why.
-
Sagas — Part 4: Design Considerations Continued
Exceptions, Cancellation, Idempotency and Isolation
-
Leaky Event-Based Microservices’ Integration
When Events are Passive-Aggressive Commands
-
Sagas — Part 4: Design Considerations
Sagas — Part 1: An Introduction Sagas — Part 2: Sagas in Distributed System Sagas — Part 2b: Sagas in Distributed Systems Continued Sagas…
-
Sagas — Part 3: Choreography Instead?
When to Choose Choreography
-
Sagas — Part 2b: Sagas in Distributed Systems Continued
Pragmatism and Boundaries
-
Sagas — Part 2: Sagas in Distributed Systems
In the previous post in this series, I briefly touched on why distributed transactions are not suitable in distributed systems:
-
Sagas — Part 1: An Introduction
Orchestration and Sagas