Where Should a Transaction End? Designing Consistency Boundaries in Distributed Java Systems

Microservices do not eliminate transactions. They force architects to decide where a transaction should end.

That decision is harder than it sounds. A business operation that was once handled inside a single database transaction may cross several services after decomposition. An order can involve inventory, payment, pricing, customer limits, audit history, and notification. The architecture may divide these responsibilities cleanly, but the business still sees one operation: place the order.

This is where many distributed systems become fragile. Teams draw service boundaries first and discuss consistency later. By then, business rules already cross databases, synchronous calls have formed long dependency chains, and eventual consistency has become a general excuse for states nobody can clearly explain.

The better approach is to begin with business invariants. First decide which facts must remain true together. Then place transaction and service boundaries around those facts. Technology comes after that decision.

Start With the Invariant, Not the Service

An invariant is a business rule that must remain true whenever an operation is considered complete. It is stronger than ordinary validation.

For example:

• A confirmed reservation must own the seat assigned to it.
• A financial transfer must preserve the accounting relationship between debit and credit entries.
• An accepted command must not create the same business effect twice.
• An order must not be marked as confirmed if the required payment authorization failed.

These rules define the real consistency boundary.

If two pieces of state must change together for an invariant to remain true, the safest design is usually to keep them inside one local transaction. Splitting them across services does not remove the rule. It converts the rule into a distributed coordination problem.

That conversion may sometimes be necessary, but it should be a conscious tradeoff. A service boundary is not free merely because it looks clean on an architecture diagram.

Three Different Consistency Problems

Architects often discuss consistency as though the system has only two choices: strong consistency or eventual consistency. In practice, a distributed workflow usually contains three different boundaries.

Figure 1. Three consistency boundaries: local atomicity, durable event publication, and eventual convergence across independently committed services. 

1. The Atomic Core

The atomic core contains state changes that must succeed or fail together. A local ACID transaction is still the simplest and strongest tool for protecting this boundary.

Consider an order service that accepts a command, creates the order, records its initial status, and saves a durable event describing the accepted order. If losing that event would leave downstream systems permanently unaware of the order, the order record and the event must be committed together.

This does not require a distributed transaction. Both records can live in the same database and participate in the same local transaction.

2. The Durable Handoff

Once the atomic state is committed, the system must communicate the result to other components. This is a durability problem, not just a messaging problem.

Publishing directly to a broker inside application logic creates a dangerous gap. The database commit may succeed while the publish fails. Publishing first creates the opposite problem: another service may receive an event for state that never committed.

The transactional outbox pattern closes this gap by storing the business change and the outgoing event in the same local transaction. A separate publisher later sends the event to the broker.

The handoff is durable because the intent to publish survives process crashes and temporary broker failures.

3. The Convergent Workflow

After the event crosses a service boundary, the workflow is no longer atomic. Each service commits its own state at a different time. The architecture must therefore define how the system reaches a valid final state.

This is where eventual consistency belongs. It should describe an explicit convergence process, not an undefined period in which anything may happen.

The design must answer:

• Which intermediate states are valid?
• How long may the workflow remain incomplete?
• What happens when a step fails permanently?
• Can a completed action be compensated?
• Which component owns the workflow state?
• How can support teams and auditors determine what happened?

If these questions have no clear answers, the design is not eventually consistent. It is merely incomplete.

A Java Boundary Using a Transactional Outbox

The following simplified Spring example keeps the order and its outgoing event inside one transaction:

@Service
public class OrderApplicationService {

    private final OrderRepository orderRepository;
    private final OutboxRepository outboxRepository;

    public OrderApplicationService(
            OrderRepository orderRepository,
            OutboxRepository outboxRepository) {
        this.orderRepository = orderRepository;
        this.outboxRepository = outboxRepository;
    }

    @Transactional
    public OrderId placeOrder(PlaceOrder command) {
        Order order = Order.create(
                command.customerId(),
                command.items());

        orderRepository.save(order);

        OrderPlaced payload = new OrderPlaced(
                order.id().value(),
                order.customerId().value(),
                order.total(),
                order.version());

        outboxRepository.save(
                OutboxMessage.pending(
                        UUID.randomUUID(),
                        "OrderPlaced",
                        order.id().value(),
                        payload));

        return order.id();
    }
}

The important detail is not the framework annotation. It is the placement of the boundary. The order and the outbox message are committed in the same database transaction. Either both exist, or neither exists.

An outbox publisher can read pending messages and publish them asynchronously. If it crashes after publishing but before marking the message as sent, it may publish the same event again. That is acceptable only when consumers can recognize repeated business effects. The outbox solves atomic handoff, but it does not remove the need for idempotent processing.

This distinction matters. Each pattern solves a specific failure window. Combining patterns without understanding their boundaries creates complexity without correctness.

Model the Workflow as State, Not as a Call Chain

A common mistake is to implement a distributed transaction as a chain of synchronous calls:

Order → Inventory → Payment → Shipping → Notification

The chain looks simple when every call succeeds. Under failure, however, it behaves like a distributed transaction without the guarantees of one.

Suppose inventory is reserved and the payment provider completes the authorization, but its response times out before reaching the order service. The order service cannot safely assume that payment failed. Retrying may create another authorization, while immediately starting compensation may cancel an order that was already paid.

These situations should be modeled as durable business states rather than hidden inside request-handling logic. The normal path moves from PENDING to INVENTORY_RESERVED, then PAYMENT_PENDING, and finally CONFIRMED. A definitive payment rejection moves the workflow to PAYMENT_FAILED, followed by inventory release and cancellation.

A timeout requires a different path. The workflow moves to PAYMENT_STATUS_UNKNOWN because the outcome is uncertain. A reconciliation step must query the payment provider or process a later payment event before deciding whether to confirm the order or continue with compensation.

Figure 2. A durable order workflow distinguishes definitive payment failure from an unknown payment result that requires reconciliation.

Each transition should have a durable cause, a stable business identifier, an expected previous state, and an idempotency rule. The component that owns the workflow must record progress before initiating the next step.

With this design, the workflow can resume after a process crash because its progress exists as data rather than only inside a thread or request stack. It also gives architects, developers, and support teams an authoritative explanation of what happened and what the system should do next.

This does not mean every workflow requires a large orchestration platform. A state table and a small coordinator may be sufficient. What matters is that intermediate states, failure paths, and recovery decisions are explicit.

When Eventual Consistency Is Safe

Eventual consistency is a good choice when temporary disagreement is acceptable, and convergence can be demonstrated.

Typical examples include:

• Updating a search index after the source record commits
• Sending confirmation notifications
• Refreshing analytics or reporting projections
• Updating recommendations or cached views
• Propagating noncritical profile changes

These operations can usually lag without violating the core business transaction.

The decision becomes more difficult around inventory, credit limits, payment authorization, and regulatory records. These domains often contain rules that cannot tolerate arbitrary intermediate states. They may still require distributed workflows, but the workflow must use reservation, versioning, expiration, reconciliation, or another explicit control.

For example, inventory does not need to be permanently deducted at the moment an order starts. It can be reserved for a limited period. The reservation becomes a first-class domain concept with an owner, an expiration time, and a release rule. That model is more honest than pretending an asynchronous deduction behaves like a local transaction.

Database per Service Is a Guideline, Not the Starting Point

Database ownership is important because shared schemas create coupling. However, “database per service” should not be applied before understanding the domain.

If two pieces of data participate in the same invariant and change together frequently, separating them can create more coupling rather than less. The services may become independently deployable on paper while requiring constant runtime coordination in production.

Sometimes the correct first architecture is a modular monolith with strong internal boundaries and one transactional database. Services can be extracted later when their business boundaries, scaling needs, and consistency requirements are understood.

This is not a rejection of microservices. It is recognition that distribution should solve a real problem. Network boundaries are useful for independent ownership, deployment, scaling, security, and fault isolation. They are costly when placed inside an invariant that demands constant coordination.

A Practical Decision Test

Before splitting an operation across services, architects should ask the following questions:

These questions should be answered before choosing a broker, workflow engine, or framework. Infrastructure can transport messages and execute retries, but it cannot decide which temporary states the business permits.

Common Boundary Mistakes

Several design mistakes appear repeatedly in distributed Java systems.

Splitting First and Coordinating Later

Teams decompose a system around nouns or technical layers, then discover that every important operation crosses several services. The resulting architecture has many services but few independent business capabilities.

Calling Everything Eventually Consistent

Eventual consistency is used as a label without defining the expected final state, deadline, or recovery path. Temporary inconsistency then becomes permanent drift.

Treating Broker Delivery as Business Correctness

A broker can redeliver a message, but it cannot know whether the corresponding business effect already occurred. Correctness must be enforced where business state changes.

Hiding Workflow State in Application Code

Retries, timeouts, and compensations are implemented as nested calls without a durable state model. After a crash, the system cannot determine where to resume.

Assuming Compensation Always Works

The design contains a backward arrow for every forward step, even when the business action is time-sensitive or irreversible.

Architecture Is the Placement of Guarantees

The central question in distributed design is not whether a system uses microservices, events, sagas, or an outbox. It is where the system places its guarantees.

Use a local transaction for the smallest set of state that must change together. Use a durable handoff when committed state must be communicated. Use an explicit workflow when multiple services must converge over time. Add compensation only where the business can genuinely support it.

Most importantly, let business invariants shape the boundaries. A clean service diagram is valuable, but it is not more important than preserving the rules that make the system correct.

Microservices make boundaries visible. Good architecture makes those boundaries honest.