Two deployables reading and writing the same tables cannot be released independently, cannot change their schema independently and fail together — which is every property a service was supposed to remove.
orders-service ──┐
├──> shop.orders ← both write. one schema.
billing-service ──┘
# the question that settles it: can one of them add a NOT NULL column
# without coordinating a release with the other?
#
# if not, they are one service with two deployment artefacts —
# which is strictly worse than one service.The shape usually arrives by accident: a second application needed some data, the database was right there, and reading from it was faster than building an endpoint. Undoing it means one service owning the tables and the other going through an API or a replicated read model. Naming it out loud is most of the work, because it is frequently defended as pragmatism when the actual cost — coordinated releases forever — has never been stated.