How can I avoid a cross aggregate transaction?

Question

Consider this simplified example: In an online ticket sale website, tickets have variable prices that change over time.

User searches for tickets. Once he finds a ticket he wants, clicks "Buy" and then a quote is issued. Quotes are persisted and they have they own locator that is sent by email. The quote page opens, showing the breakdown of what he is going to pay, and a button to pay. At this point, the ticket is still available for others. If the user clicks on "Pay now", a payment process starts and a Purchase Order is issued with his details.

When a purchase order is paid, the quote status must be set as "Accepted" and reference the purchase order; the ticket status is set as "Sold".

As per requirements, this must happen in an atomic fashion, meaning that it is not acceptable to have a paid purchase order referencing a non accepted quote, or a non sold ticket at any given time. Essentially, eventual consistency is not allowed.

There are two big aggregates, Quote and PurchaseOrder. The first manages the breakdown calculation, taxes, etc... The second manages payment details for a quote, payment event raising, etc... The problem I have is that right now it seems I have to use a transaction across ticket, quote and purchase order when the last is paid.

How may I model this honoring the "Transactions should not cross aggregate boundaries" rule?

Answer 1

You need a process manager/saga that do exactly what you need without using transaction that spawn multiple aggregates.

Basically that Saga would reserve the ticket right before the payment begins and would markTicketAsSold after the payment is successful or releaseTheReservation after the payment is failed.

This process and the invariant that a reserved or sold ticket cannot be reserved again would ensure that the system as a hole is in the correct state at all times.

As per requirements, this must happen in an atomic fashion, meaning that it is not acceptable to have a paid purchase order referencing a non accepted quote, or a non sold ticket at any given time. Essentially, eventual consistency is not allowed.

This does not seem to be a valid invariant. The invariant should be "a sold ticket cannot be sold again". Carefully defining the business invariants will help you in designing the aggregate boundaries and correctly modeling the long running processes.