Meng Lin's Byte-Wise Words

The journey to break down the monolith to microservices in order to accelerate software delivery lies many challenges, including defining bounded contexts as DDD aggregates; connecting the contexts with domain events using either orchestration or choreography; and the mechanism to publish these domain events reliably and persist and consume the events consistently. An event-centric way of structuring the business logic and aggregate persistence is called event sourcing. Problem with Traditional Persistence Traditionally, aggregates are represented as classes or objects in applications. It has worked well for monolith systems. Despite being hard to change, maintain and scale, there are also several limitations to this approach. Object-Relational Impedance Mismatch The object-relational impedance mismatch problem describes the conceptual mismatch in serving relational data using an object-oriented programming language. This tends to have a few common symptoms. Relationships are represen...

Intent  When moving to microservices architecture, one of the biggest challenges is dealing with data consistency among a swarm of microservices. Microservices are loosely coupled and separated by bounded contexts, such as a transaction through the trade lifecycle, which needs to be broken into local atomic transactions that can be executed by individual microservices within their own domain (not the other way around, i.e. a microservice knowing the internal constructs of other microservices’ databases). In order to achieve eventual consistency within a business transaction , the microservices need to be able to: persist data in relation to their own domain, and  publish events to the event broker upon changes to asynchronously trigger the execution of other processing units. These are two distinct operations, often referred to as dual write . Because they are two separate operations of an atomic transaction, it became a source of consistency issues, performance dips and scal...