I love event sourcing and I’m really digging the event store. Where it does pose a bit more of a challenge over an RDBMS is when trying to solve a unique constraint. Specifically when you are trying to create a unique identifier for an Investor (in our current business case). You could create a stream naming pattern that uses email address. For example [email protected] and then when a new Investor account is created you check for the no_stream expectedRevision so you will get an error if it exists. I don’t want to use email address as email addresses can change and I sometimes find it convenient to have multiple system accounts linked to the same email address. I see two options. 1) Create a unique uuid for each account. On account creation create a stream with the uuid e.g. user_. Create a projection into a cache (e.g. redis) that looks up the uuid via username. When accounts are created lookup into the cache to see if the username is unique. This would allow the event store to hold a stream without having to migrate to a new stream on username change. This is more complexity then I want to deal with right now so I'm going to go with option two. 2) Just have the user select a unique username (duh). Then you get stream_ and don't allow them to change it or accept the technical hit of migrating to a new stream should it change (you would have to migrate all events to the new stream and, if you store a username reference in the portfolio aggregate you would have to update those references as well).