I always love reading about event sourcing, the different approaches and trade offs, hoping one day I can use it, somewhere... But I never thought somewhere wo

I always love reading about event sourcing, the different approaches and trade offs, hoping one day I can use it, somewhere... But I never thought somewhere would be PHP where it is essentially build the world and destroy the world per request. I would of presumed PHP would be poorly suited for event sourcing since you have no in-memory cache to help optimize performance. Thus for any accepted command where you have to revive the aggregate then you need to load and deserailize a snapshot (if one exists), and then deserialize any subsequent events and replay them, before you can apply the latest event to the aggregate. Does this concern you? However removing a layer of caching probably simplifies a lot of things, and being completely stateless I guess could make scaling the app layer easier. One thing that's not clear is how you handle locking of the aggregate (unless you restrict php_fpm to one worker process)? Also the order in which you handle event persistence, shouldn't the event be persisted first before dispatching on some bus, what happens if the server crashes prior the persistence but after a dispatch where something interesting happens?