Register or log in to access this video
Every architecture tells a story, and most tragedies begin with messy data. This talk shows how clear ownership, contracts, and events can turn complexity into clarity and evolution into design.
New York • September 15-16, 2026
Full LDX3 lineup is here 🙌
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.
Key takeaways
- How to treat aggregates as transactional boundaries and keep writes local to the owning domain
- How to replace table access with contract-based read models to decouple evolution
- How to use events and process managers to coordinate cross-aggregate workflows without big transactions
- How to enforce discipline with architectural fitness functions focused on data, not just code
- How to recognize when data lifecycles and governance push you beyond the monolith and how to decompose along existing seams”
