Advanced patterns for use with Event Sourced systems - James Geall - DDD Europe 2023

Domain-Driven Design Europe 2023
dddeurope.com - / ddd_eu - newsletter.dddeurope.com/ / domain-driven-design-e...
Organised by Aardling (aardling.eu/)
There are a set of simple rules for building event sourced Aggregates that work quite well, in most cases. However, there are a handful of common business cases that when implemented using these rules generate a tangled mess of accidental complexity. One advanced pattern that can help in these situations is the process manager. Understanding when to use them, how to build them and the trade-offs that are being made can be critical to succeeding.
This talk will give attendees an understanding of what process managers are, when to use them, how to build them and pitfalls that can cause problems. Code examples of both business and technical problems that process managers can help solve will help reinforce these ideas with stripped down implementations from systems currently in production.
About James Geall
Over 2 decades of distributed programming experience with a focus on messaging and 12+ years in the Event Sourcing/DDD space. Multiple event-sourced systems in production across a variety of business verticals including Pharmaceutical, Finance and Logistics. I currently work for Event Horizon Consulting delivering training on advanced DDD, CQRS and Event Systems.

[@mehdigoharinezhad1368]

Thanks it is impressive and useful talk❤

[@JohnMcclaned]

23:50 - great idea to zoom in on his face when he is explaining something specific on his slides lmao

[@vincentcifello4435]

I don’t see how that Reservation pattern could possibly work with concurrent users.
Is there a more detailed description?

[@ByronRuth]

There is still the consistency boundary around the availability of tickets/orders (effectively a counter) which means concurrent orders can be in flight, but only those that are reserved and finalized prior to running out of tickets will be accepted. Any other orders that are in-flight won't be finalized since the tickets ran out and thus are rejected by the end of the lifecycle.

[@vincentcifello4435]

​ @ByronRuth Thank you, Byron.
The ReserveTicketCommand reads and updates the TicketInventory resulting in a TicketsReservedEvent. The ProcessManager, based on that fact, assigns tickets to the order, but the deed is done as soon as the TicketReservedEvent occurs.
If 2 concurrent ReserveTicketCommands read the TicketInventory (say one ticket left), it seems that this could result in 2 TicketReservedEvents.
The question is how can this be implemented to prevent such an occurrence. (Even in a SQL database table within a transaction, concurrent read value->do a check->update value operations can fail under high concurrency unless you use pessimistic type locking.)
JG qualifies this by saying "if you really have a problem with that, you can shard it into pulse (is that what he said?)" Why would he say this? What problem is "made small enough"?
I just don't see how the ReserveTicketCommand->TicketInventory->TicketReservedEvent could possibly be implemented to avoid the potential concurrency issues.

[@vincentcifello4435]

@@ByronRuth Thank you, Byron.
ReserveTicketsCommand -> TicketInventory -> TicketsReservedEvent. Once the TicketsReserved event occurs, the deed is done. The tickets have already been reserved. No? He doesn't mention any other checks of inventory.
The issue is how TicketInventory can possibly be implemented without having potential concurrency issues resulting in negative inventory.
Even in a SQL database table's single row, concurrent transactions that read value->do a check->update value can fail under high concurrency without performance-destroying pessimistic locks.
JG says something about "if you have a problem with that you can shard it into Pulse".Is that meant to address the potential concurrency issues? What problem is he talking about?