How is the data consistency problem between services solved?

In a microservice architecture there is no single database, so data consistency is achieved through event exchange and coordination of actions between services. The goal is to achieve logical consistency without global transactions.

#1. Event-driven approach (eventual consistency)

Each service publishes events about its changes, for example "Order created", "Payment confirmed". Other services subscribe and update their own data. This achieves eventual consistency: the data becomes consistent after a short delay.

Example: The orders service creates an order → publishes an event → the delivery service adds its own record.

#2. Saga pattern

A large business operation is split into a series of local steps across different services. If one of the steps fails, compensating actions are executed to roll back the previous changes.

Example:

1. Create the order →
2. Reserve the item →
3. Charge the payment. If step 3 fails, steps 1-2 are rolled back ("cancel the order", "release the item").

#3. Outbox pattern

To make sure an event is not lost between writing to the database and sending it to the broker, the service first writes it to an outbox table and then reliably publishes it. This prevents desynchronization between local and external changes.

#4. Idempotency and retries

Each service must be able to safely repeat operations. Even if an event or request arrives twice, the result stays correct.

#5. Monitoring and consistency control

Background checks (reconciliation jobs) are used that periodically compare data between services and fix discrepancies.

Summary:

In microservices, consistency is achieved not through a shared transaction, but through managing events, sagas, and idempotent operations. This provides flexibility and fault tolerance, but requires carefully designed interaction logic between services.