I've been developing software for a number of years and have found the event store concept to be quite interesting, as it will neatly avoid a number of pain points I've encountered over the years. However, three things remain for me before I can really give this a go.
The first is, how to handle querying an event store. Now, I understand that you would basically support such queries by setting up tables that essentially cache results from the stream of events, probably in a denormalized fashion. How would you implement that though? Would you just have another listener for the event that updates the table? What if you are allowing search for practically any field on a particular object? When you update the schema that is used in the search table, wouldn't you have to rerun whatever updates the table for all records? How hard is this to pull off cleanly?
The second is, how do you handle large chunks of data? That is, lets say you are storing blog posts and the like. How do you deal with an arbitrarily large wad of text that receives a fair number of updates? Would you just run the new version through something that produces a diff against the old version, or would you use another strategy?
The third is, how do you handle bulk updates from outside? Let's say that large documents come in and each represents an aggregate root. Do you break it up into a series of smaller updates (and potentially lose sight of how it came in through a bulk update), or do you just have a massive, nasty event for this particular use case.
I realize almost all of the above are just begging for an answer of "it depends". But what's the general approach?