Why event sourcing for a multi-tenant platform

When I started rebuilding Symplicia, the persistence question came up very quickly. A classic CRUD architecture would have been enough for an MVP, but it makes it hard to trace state changes on a rental property — who changed what, and when.

Event sourcing with EventStoreDB solves this problem at the root: every change becomes an immutable event. You can rebuild the state of a listing at any point in time, and it massively simplifies auditing and customer support.

class LeaseCreated {
  constructor(tenantId, propertyId, startDate) {
    this.tenantId = tenantId;
    this.propertyId = propertyId;
    this.startDate = startDate;
  }
}

The real cost is the upfront complexity — you have to think in events from the domain modeling stage onward, and it changes how you write tests. I'll come back to that in a future post about the five-level testing strategy I use on this project.

To go further on the topic, the EventStoreDB documentation (https://www.eventstore.com/) remains the best resource for understanding the implementation patterns.