APIs, APIs, APIs... I feel like building an API for everything which goes over the wire is a must-have today! Yes it makes sense for decoupling purpose, access control etc (all the things we learned from OOP design principle books when we were in school) but come on, REST API for internal database access when there is something like SQL over JDBC/ODBC/WhateverBC ?? So I have to study the REST API documentation for applying simple where-statements but in API manner...

And your rest API server will probably use ODBC for data access, nice

Exactly this is the case @HitWRight

Depends on your system.

I like systems when only ONE part writes to SQL data base, but ANY part can read.

The problem is cache managment.

So a lot of people with no distributed cache (liuke redis) go for ONE big API server with APIs for read/write (and cache is applied there) and all "satelite" systems just call APIs

@NoToJavaScript hm.

I think you hit the nail on the head, though Redid as a cache must not be.

But in general @johnMurdoch decoupling a database in a monotholic application is.... Hard.

You have to think far outside the box and be very strict.

Common anti patterns are e.g. usage of an ORM and spreading the ORMs "comfort" features like types around.

I'm not saying impossible.

But it's a delicate and very painful task as usually you need a careful review system combined with an observer with permission to NAK PRs.

Otherwise... You'll fight a lost cause.

As soon as one dev puts his hand in the honey jar and breaks the layered design, it's over.

APIs eliminate this partially.

It's a cludgy workaround as you can the just rewrite when an app becomes such a clusterfuck that it's beyond salvation.

That's the sad truth about micro services.

They accept that bad things happen and try to minimize the collateral damage.