How to design MongoDB data model to store Event Sourcing events

Question

If I create a single table (or document in document databases) per aggregate type,I can merge databases or shard them whenever I refactor the write side's microservices, and as the result the application becomes more scalable, and it also increases the speed of loading events.

Are there any side effects I should be aware of while I'm designing the event store like that?

Edit:

I'm currently using MongoDb.

What if I create a collection per aggregate id ? Or a database per aggregate type, and a collection per aggregate id ...?

Is that problematic in performance, ease of data administration, maintainability, or further scalability?

Answer 1

If I create a single table (or document in document databases),I can merge databases or shard them whenever I refactor the write microservices, and as the result the application becomes more scalable.

Are there any side effects I should be aware of while I'm designing the event store like that?

I haven't seen any authoritative discussion of that design.

There was a discussion in the event sourcing community about having a separate table for each type of aggregate. You can find that discussion here. Executive summary: the more experienced practitioners seemed to be startled that anybody would do that on purpose.

One thing that you should keep in mind is that while events are real (they describe something of interest to the business), aggregates are artificial. You are probably going to be unhappy if redesigning your aggregate boundaries requires that you move your events all over the place.

The following may be helpful

• https://github.com/NEventStore/NEventStore.Persistence.MongoDB
• http://www.slideshare.net/dbellettini/cqrs-and-event-sourcing-with-mongodb-and-php
• http://blingcode.blogspot.com/2010/12/cqrs-building-transactional-event-store.html