A developer platform composes Postgres, an auth service, storage, realtime subscriptions and an auto-generated API into one product. What makes that modular rather than merely multi-component, and what is the test?

The test

Modularity is measured by replaceability, not by the number of boxes. The question is: could one component be swapped for a different implementation without touching the others?

A platform built on Postgres where every component reaches into every other component's tables has five deployables and one module. A platform where realtime consumes the write-ahead log through a defined interface, auth owns its own schema and exposes claims, and storage keeps metadata behind an API has five deployables and five modules.

What makes this case interesting

The shared database is simultaneously the product's greatest strength and the biggest threat to its modularity. Because everything is Postgres, row-level security can be one mechanism across storage, realtime and the data API — an enormous simplification for users, and genuinely good architecture, because it puts one authorisation model behind one enforcement point.

The threat is that shared substrate invites shared state, and shared state is exactly what modularity forbids. The discipline is to treat "we both use Postgres" as an infrastructure fact and not a licence to read each other's tables.

The signal that modularity is real

Modularity that exists only in a diagram is detected by a single question: when was the last time you replaced one of these and what did it cost? Teams that have actually swapped an implementation — a storage backend, an email provider, a search engine — know where the leaks are. Teams that never have usually discover during the attempt that the interface was aspirational.