Session

Your problem isn’t the monolith. It’s the data.

We often blame the shape of a system for its troubles: “It’s the monolith,” or “We moved too slowly to microservices.” In practice, the rot sets in earlier and deeper. It begins when anyone can write to any table, when cross-domain joins sneak into hot paths, when lifecycle and retention rules are inconsistently applied, and when teams share a database but not a vocabulary. The result is a system that erodes from the inside out. Not because it is a monolith, but because ownership ends at the code and never reaches the data.

This talk argues that data must be the structuring force of architecture. We will journey with Penultimate Markets, a global marketplace that scaled from a single deployment to a distributed platform, and see how disciplined data ownership shaped every step. In the monolith phase, aggregates anchored transactional boundaries; write logic lived inside the owning domain; other teams consumed contract-based read models rather than reaching into tables. Architectural fitness functions made these rules executable: blocking cross-domain joins, enforcing expand/contract migrations, and validating event and read-model contracts continuously.

As the platform expanded, different domains began to pull outward. Search needed low-latency regional scaling; tax required immutable records and long retention; payments demanded isolated failure domains and stricter SLAs. Instead of a flag day, the same data-first discipline guided decomposition. Seams defined by aggregates, events, and read models became extraction boundaries. Autonomy followed data ownership; duplication became intentional; consistency was managed with explicit choreography or orchestration rather than sprawling transactions.

The point is not to romanticize monoliths or glorify microservices. It is to show that architectures endure when teams align on data lifecycles, not just APIs. If you can define, defend, and evolve data boundaries, your monolith will remain modular longer, and your inevitable decompositions will be evolutionary, not traumatic. You leave with pragmatic techniques you can adopt on Monday: encode ownership, publish contracts, verify them in CI, and make migrations safe by design. Do this, and your system will grow with your business rather than against it.

Prem Chandrasekaran

Author, Coding Architect, Technology Leader, DDD Enthusiast

Chester Springs, Pennsylvania, United States

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top