[davidcaseria]

Avoiding large data migrations is one of the reasons to consider if using Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) is right for the application domain. It seems in this example the domain events haven't changed (i.e. subscription created, subscription canceled) but the logic enforcing subscriptions has (i.e. only one subscription then allowing multiple). If the events were stored in an append only journal then the subscription business logic just needs to change and no data needs to be migrated. Additionally, since the catalyst for this change seemed to be query side performance, the query service can be optimized for reading the records separate from the command service that writes to the event journal.

Event sourcing isn't without it's difficulties but if the domain is pretty well understood then it can be a very powerful pattern.

Stripe has an awesome product and seemingly an equally great engineering culture. I wonder if they have debated using CQRS/ES.

[chatmasta]

Does this require a separate data source (e.g. a message queue) to ingest and log the events before reacting to them? Or could you retroactively use the mongodb oplog? I imagine there is way too much data for the oplog to be feasible in this case. And if you didn't design the system from day 1 around an event model, wouldn't it be difficult to retroactively introduce this new architecture?