Save an order and outbox event in one Spring transaction

• Use one Spring transaction for both database writes.
• Create the event payload from the committed business intent, not a mutable entity graph.
• Give every event a globally unique stable ID.
• Do not publish to the broker inside the order transaction.
• Assume the publisher may deliver an event more than once.

1. Create and save the order inside an application-service transaction.
2. Build a versioned event DTO with the saved order ID.
3. Serialize that DTO and save an outbox row before commit.
4. Let a separate publisher claim pending rows, publish, and mark progress.
5. Test both commit and rollback boundaries, then test publisher retry separately.

@org.springframework.stereotype.Service
class PlaceOrderService {
    private final OrderRepository orders;
    private final OutboxRepository outbox;
    private final com.fasterxml.jackson.databind.ObjectMapper json;

    PlaceOrderService(OrderRepository orders, OutboxRepository outbox,
                      com.fasterxml.jackson.databind.ObjectMapper json) {
        this.orders = orders;
        this.outbox = outbox;
        this.json = json;
    }

    @org.springframework.transaction.annotation.Transactional
    java.util.UUID place(PlaceOrder command) {
        var order = orders.save(Order.place(
            java.util.UUID.randomUUID(), command.customerId(), command.lines()));

        var event = new OrderPlacedV1(
            java.util.UUID.randomUUID(), order.getId(), order.getCustomerId(),
            java.time.Instant.now());
        outbox.save(OutboxMessage.pending(
            event.eventId(), order.getId(), "OrderPlaced", 1,
            writeJson(event), event.occurredAt()));
        return order.getId();
    }

    private String writeJson(Object value) {
        try { return json.writeValueAsString(value); }
        catch (com.fasterxml.jackson.core.JsonProcessingException e) {
            throw new IllegalStateException("Cannot serialize outbox event", e);
        }
    }
}

// A separate bounded publisher claims pending rows and retries delivery.
// Consumers deduplicate by eventId because publish and mark-complete are not atomic.

The command performs two bounded inserts in one transaction. Publisher work is proportional to claimed batch size; indexes on pending status and creation time keep scanning bounded.

• Serialization failure must occur before commit and roll back the order.
• A crash after broker acceptance but before marking published causes duplicate delivery.
• Large payloads make the database a message store; include only the durable contract fields.
• Event schema changes require versioning because old pending rows may outlive a deployment.

• Force outbox persistence to fail and assert no order commits.
• Place an order successfully and assert one matching pending event with a stable ID.
• Simulate publish success followed by mark-complete failure and verify retry uses the same event ID.
• Verify two different orders never share an event ID.

• Publishing before commit can announce an order that later rolls back.
• Publishing after commit without an outbox can lose the event on process failure.
• Generating a new event ID on every retry prevents consumer deduplication.
• Serializing the entire entity graph creates an accidental unstable contract.