At Meesho-scale marketplace growth, catalogue, pricing, order and logistics teams all read and write one shared product table, each deploying schema changes independently. Which kind of coupling is this, and why does it get worse rather than plateau?

Why it compounds

A shared mutable table is coupling with no upper bound on the number of participants. Every new consumer adds a constraint on every future change, so the cost of a schema migration grows with the number of pairs of teams involved, not linearly with the teams themselves.

Concretely, the failure sequence in a fast-growing marketplace looks like this:

• Nobody owns the schema, so nobody can say a column is safe to drop. Columns accumulate and are never removed, because removal requires proving a negative across teams.
• Migrations become cross-team events. A NOT NULL added by the pricing team breaks a nightly logistics job that nobody in pricing knew existed.
• Deployment order becomes a dependency, which is the thing service decomposition was adopted to avoid.
• Locking becomes a shared fate. A long-running catalogue backfill holds locks that stall order writes, and the order team's dashboards show a database problem with no application cause.
• Semantics fork. status = 3 means one thing to logistics and another to payments, and the divergence is invisible because both are reading the same column.

The resolution, in order of cost

1. Assign ownership — one team owns the table and the schema. This costs nothing and stops the worst of it.
2. Give the others a contract: a read API, a replica, or a change-data-capture projection they own. Reads are the easy half and usually the majority of the traffic.
3. Move writes behind the owner's API, which is the expensive step and the one that actually removes the coupling.
4. Split the table only if the access patterns have genuinely diverged. Splitting first, without ownership, produces the same problem across two tables plus a distributed join.

The trap is starting at step four, because it is the most architectural-sounding, and skipping step one, because it sounds like process rather than design.