Transaktionsverwaltung in Microservices

In a monolithic application, a single database handles all transactions, ensuring data integrity with ACID properties (Atomicity, Consistency, Isolation, Durability).

With microservices, your business logic is split across many independent services, each often with its own database. This introduces significant challenges for managing transactions that span multiple services. How do you ensure an operation involving several services either fully completes or fully rolls back?

In a monolithic application, a single database ensures transactional integrity:

• All operations for a business transaction occur within one database.
• ACID properties are guaranteed by the database.

In microservices, each service usually owns its data:

• A single business transaction might involve multiple services and databases.
• Traditional ACID transactions cannot span these boundaries directly.

ACID properties are fantastic for single, centralized databases. However, they don't naturally extend to distributed systems like microservices:

• Atomicity: Hard to guarantee all-or-nothing across independent services.
• Consistency: Difficult to maintain immediate consistency across multiple databases.
• Isolation: Challenging to isolate concurrent changes across services.

Trying to enforce global ACID often leads to tightly coupled services and reduced scalability.

You might wonder if you can simply use a "global transaction" across all microservices. The short answer is: it's generally not practical or recommended.

• Global transactions require a coordinator to lock resources across multiple databases.
• This introduces significant overhead, reduces performance, and creates a single point of failure.
• It tightly couples services, defeating a core benefit of microservices: independence.

This approach often leads to distributed deadlocks and poor availability.

In a distributed system, any service can fail at any time, independently of others. This is known as a partial failure. Imagine an online order:

• Order Service creates an order.
• Payment Service processes payment.
• Inventory Service deducts stock.

If the Inventory Service fails after payment but before stock deduction, your system is in an inconsistent state: payment taken, but no stock deducted.

Without global ACID transactions, how do we keep data consistent across multiple services? This is a core problem in microservices.

Traditional "immediate consistency" (where all data is consistent right after a transaction) is often sacrificed for availability and scalability. Instead, we often aim for eventual consistency.

This means data might be temporarily inconsistent, but the system guarantees it will eventually become consistent.

The Two-Phase Commit (2PC) protocol is a classic way to achieve atomic transactions across distributed databases. It involves two phases:

1. Prepare Phase: A coordinator asks all participants to prepare to commit.
2. Commit Phase: If all participants are ready, the coordinator tells them to commit; otherwise, it tells them to rollback.

While 2PC ensures atomicity, it comes with significant drawbacks in microservices: it's blocking, slow, and prone to coordinator failure.

Given the limitations of traditional ACID and 2PC in distributed environments, microservices architectures require different approaches to manage business transactions.

These alternative patterns often involve:

• Breaking down large transactions into smaller, independent local transactions.
• Using asynchronous communication (e.g., message queues).
• Implementing compensating transactions to undo actions if a later step fails.

These patterns prioritize availability and partition tolerance over strict immediate consistency.

Consider an online order that involves multiple services:

1. Order Service receives order.
2. Customer Service validates customer credit.
3. Payment Service charges the customer.
4. Inventory Service reserves items.
5. Shipping Service dispatches.

If the Inventory Service fails to reserve items after payment, we need a way to refund the customer. This is where alternative patterns come in, coordinating these steps and handling failures.

Traditional ACID transactions are typically designed for single, centralized databases. When a business transaction spans multiple microservices, each with its own database, new challenges arise.

In this lesson, we explored the inherent difficulties of managing business transactions across multiple microservices. We learned that:

• Traditional ACID properties don't directly apply across service boundaries.
• Global transactions (like 2PC) are often avoided due to complexity, performance bottlenecks, and reduced availability.
• Partial failures are a constant threat, leading to inconsistent states.

These challenges highlight the critical need for alternative patterns like Saga, which you'll learn about in upcoming lessons, to ensure data consistency in a distributed world.