The Introverted Architect

Sign in Subscribe

Architecting for Change - Part I: Why Does It Matter?

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 enhancements... the list is almost endless. Hence, change is inevitable, and systems must be designed to accommodate it. They need to be evolvable. Systems not designed with change in mind risk eroding into

The Hidden Complexity of CRUD

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 approach appears intuitive and easy. After all, CRUD operations map neatly to basic data persistence actions, making it straightforward to manipulate data over HTTP.

The Evolution of Observability

The Evolution of Observability

What is Observability? Observability's origin story starts in control theory. Control theory is a field of engineering and mathematics that deals with understanding and influencing dynamic systems to achieve desired outcomes. Control theory highlights the importance of determining a system's internal state by observing its outputs.

Evaluating an Asynchronous Processing Design

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 to provide direct feedback, but I realized this would be an excellent topic for a blog post. Overview The diagram above illustrates a cut-down version of

Targeted Event-Carried State Transfer

Targeted Event-Carried State Transfer

Another flavour of microservices’ integration

Event-Carried State Transfer Integration in Microservices

Event-Carried State Transfer Integration in Microservices

Re-designing a Leaky Microservice Integration

Re-designing a Leaky Microservice Integration

Embracing Behavioural Coupling

Read Models Spanning Microservices’ Boundaries

Read Models Spanning Microservices’ Boundaries

Or glorified data caches

Event Sourcing — Oops, wrong Aggregate Boundary

Event Sourcing — Oops, wrong Aggregate Boundary

How I shared streams to split an aggregate and why.

Sagas — Part 4: Design Considerations Continued

Sagas — Part 4: Design Considerations Continued

Exceptions, Cancellation, Idempotency and Isolation

Leaky Event-Based Microservices’ Integration

Leaky Event-Based Microservices’ Integration

When Events are Passive-Aggressive Commands

Sagas — Part 4: Design Considerations

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?

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

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

Sagas — Part 1: An Introduction

Orchestration and Sagas

Re-designing an Aggregation Microservice — Part 3

Re-designing an Aggregation Microservice — Part 3

Re-designing an Aggregation Microservice — Part 1

Re-designing an Aggregation Microservice — Part 2

Re-designing an Aggregation Microservice — Part 2

In the first post in this series, I introduced the current design of the reporting service. And discussed some of the issues with that…

Re-designing an Aggregation Microservice — Part 1

Re-designing an Aggregation Microservice — Part 1

I was involved in a recent discussion regarding how to improve a reporting microservice that aggregates data from numerous services. There…

Re-implementing the Outbox Pattern in MongoDB

I have blogged previously about how we implemented the Outbox pattern on top of SQL Server and Websphere MQ to avoid distributed…

DTC-Enforced Constraints

DTC-Enforced Constraints

There are numerous blogs and talks out there about why you should or should not use distributed transaction coordinators (DTC) and they…

Avoiding Distributed Transactions — Outbox Pattern

Avoiding Distributed Transactions — Outbox Pattern

I’m currently architecting a payment system for domestic payments for a UK bank. This is a greenfield system that is going to consist of a…

Scalability and SOA — Part 3 (UI Composition)

Scalability and SOA — Part 3 (UI Composition)

In part 2, I briefly covered Event-Driven SOA and why event messages are preferred for communication between services. I also stated that…

Scalability and SOA — Part 2 (Event-Driven SOA)

Scalability and SOA — Part 2 (Event-Driven SOA)

In the previous post in this series, I wrote about scaling up vs out, why we chose scaling-out and why layered service models are not the answer. In this post, I will delve deeper into vertical services and how they help with scaling out strategies. Services in Service-Oriented Architectures If

Scalability and SOA - Part 1

Scalability and SOA - Part 1

In this series of posts, I will discuss the challenges I faced developing a highly scalable and highly available SaaS product using a Service-Oriented Architecture. The first question you might want to ask yourself when designing a scalable system is whether to scale out or up. When scaling up (vertical