Event‑Driven Architecture and Distributed Transaction Consistency in Microservices

Continuing from the previous piece on domain‑driven design, the author highlights that while a rich (charged) model brings many benefits, it also introduces drawbacks that are amplified in distributed microservice architectures, especially concerning transaction consistency.

ACID Principles – The article revisits Atomicity, Consistency, Isolation, and Durability, noting that these guarantees are easy to achieve in a monolithic system with a single relational database but become problematic when aggregates are split across services.

In microservices, distributed transactions often resort to two‑phase commit (2PC) or rely on eventual consistency to preserve the CAP trade‑off, accepting that strong consistency may be sacrificed during partitions.

Example: Order and Inventory – When an order is placed, the order and inventory services each maintain their own databases. A single transaction cannot update both, so the system must use an event‑driven approach: the order service emits an OrderCreated event, the inventory service consumes it, locks stock, and emits an InventoryLocked event, after which the order service marks the order as confirmed. If stock locking fails, a LockFail event triggers order cancellation.

The author argues that event‑driven architectures eliminate the need for explicit locks, improving concurrency for high‑traffic scenarios such as flash sales.

Domain Services and Materialized Views – Complex queries that span multiple bounded contexts (e.g., joining orders, users, and products) are off‑loaded to a dedicated view service that maintains a materialized view, often backed by a read‑only relational store or Elasticsearch, trading storage for query performance.

Bounded Context Data Coupling – To avoid tight coupling between services (e.g., product information needed by marketing, pricing, cart, and order services), the article suggests duplicating necessary data into each context via events, reducing cross‑service dependencies.

Ensuring Eventual Consistency – Reliability of message delivery and service availability are critical. The author mentions using JMS acknowledgments, local transaction tables (insert event record within the same DB transaction as the business change), and background workers to reliably publish events.

Local Transaction Pattern – Steps: (1) create the order, (2) insert an OrderCreated record into an Event table within the same DB transaction, (3) a scheduled task scans the table and publishes pending events to the message queue, marking them as sent. This guarantees atomicity between business data and event emission.

Improvements include using database binlog tools (Canal, GoldenGate) to stream changes without polling, though they tie the solution to specific DB implementations.

Event Sourcing – The article briefly touches on storing only the initial state and subsequent events, reconstructing entity state in memory, noting its complexity and limited applicability.

Finally, the author reflects on the role of architects: they should be technology users, not believers, balancing technical trade‑offs with business needs, and making informed decisions about adopting new patterns such as RESTful APIs, microservices, or event‑driven designs.

Images illustrating the order‑inventory flow, materialized view architecture, and local transaction workflow are embedded throughout the article.