Stop passing objects across services. Pass IDs.

The problem that kills shipping speed

You build a feature.

It is a "small" change, maybe adding one field, one flag, one extra bit of data.

Then you realize you have to:

• Update two services
• Update three DTOs
• Coordinate a release
• Update tests that do not even live in your repo

That is not you being bad at planning.

That is coupling.

The cold logic

When modules are glued together by shared state, every change becomes a negotiation.

Even if you are a tiny team, you still pay the coordination bill.
It shows up as context switching, longer review cycles, and "wait, who owns this?" threads.

Over time, your velocity drops and your maintenance surface area grows.

Rule of the Bolt

The idea is simple.

Across module boundaries, the only stable connection should be an immutable identifier.

Not a 200 field object.
Not a shared table.
Not a magic JSON blob everyone silently depends on.

Just an ID.

Example:

• Instead of passing a full User object around, pass user_id
• If another module needs user data, it asks the user module through an explicit API

The bolt stays stable.
Everything behind it can change without breaking other modules.

The trap that breaks independence

The shared database or API endpoint.

It feels fast.
It is also a welded joint.

Change a column and you just created an unplanned integration project.

A practical way to apply this without rewriting your app

1. Pick one boundary that causes the most coordination pain
2. Replace cross boundary object sharing with *_id
3. Make the owner module the only source of truth for its data
4. Stop letting other modules reach into its tables

This is "scale by subtraction" applied to software architecture.
You remove hidden sync work instead of adding process to manage it.

Discussion starter

If you are building a SaaS with 1 to 5 engineers, what is your rule of thumb for when shared DB or endpoint access stops being a shortcut and starts being a long term drag?