Teaching scenario. This is a model case, not a description of a specific deployment or organisation.
Starting point
An order system needs to expose status to a customer portal. To meet a deadline, the portal receives direct read access to its database. Later it also gets permission to update a delivery address because it seems to be just one column.
What begins to break
- The portal interprets a status value differently after the source system changes its meaning.
- A schema migration requires coordinated deployments.
- The portal updates addresses without the order system's validation and business rules.
- Database access makes it harder to constrain and audit business operations.
The decision behind the problem
An internal data model became an integration contract, then another system gained write access to it. Tables and columns became an informal API without versioning or explicit ownership. Controlled analytics or a read replica are different decisions from sharing a transactional database and write logic.
A better approach
- Establish who owns orders and delivery addresses. Route writes through that owner's explicit contract and validation.
- Choose the read mechanism by freshness needs: an API for current status, or events and a portal-owned read model when delay is acceptable.
- Version contracts and plan compatibility during migration. Monitor lag, errors and discrepancies.
- If direct access is temporary, limit its scope, set an end date and plan the transition.
Review questions
Who can change the data? How current must the portal view be? How do both systems survive a change to the schema or status meaning?
The boundary of data ownership should also be a boundary of writes.
Discuss this article
Share a constructive observation or an anonymised example. Comments are checked by AI before publication. Uncertain cases go to the moderator.