
Event sourcing in PHP - ohmygosh
http://www.schibsted.pl/2016/03/time-travelling-with-event-sourcing/
======
nowprovision
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?

