Why is direct access to another service's database an anti-pattern?

Direct access to another service's database is an anti-pattern, because it violates the key principles of microservice architecture: isolation, loose coupling, and independent deployment.

#1. Violation of responsibility boundaries

Each microservice owns its own data and business logic. If another service accesses its database directly, it effectively interferes with its internal structure: independence and safety are lost.

Example: the "Delivery" service reads the "Orders" tables directly. If "Orders" changes its schema, "Delivery" breaks.

#2. Inability to update independently

Shared tables create tight coupling. You cannot change the database structure without affecting someone else's code: this kills the idea of independent releases.

#3. Consistency and transaction problems

With direct access, it is impossible to safely synchronize changes between services. Each service must manage only its own transactions, not global ones.

#4. Loss of security and control

Shared access to the database opens up the risk of unauthorized changes and errors: one service can corrupt another's data.

#5. No versioning or contracts

APIs can be versioned and controlled. A database cannot. Any schema change immediately breaks consumers.

Summary:

Direct access to another service's database is like reaching into the "internals" of someone else's module. Communication should go only through a public API or events, to preserve the isolation and resilience of the whole system.