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

[@JohnMcclaned]

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

[@Francis-b9e]

this save my life

[@jeafoo]

Please share a link to the referenced book - Patterns of Software Architecture 5 (POSA5)

[@racm2023]

Watch in 1.25x 😂

[@mehdigoharinezhad1368]

Thanks it is impressive and useful talk❤

[@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?