so... i'm like 90% sure this is just a straight up anti pattern but i want to check myself. If you have a single database, with just the one default schema, but a bunch of different services all accessing it - their respective service accounts having overlapping read and write perms on various tables - that's not a valid "microservice architecture", right?

it feels really sloppy to me but i'm just wondering if there's some service architecture model that someone has seen evangelised somewhere that's meant to be implemented in this way

I would expect those service accounts to get each others data from, you know, a service layer :D

you would think, yea...

@PeterVandivier I don't see why it couldn't be. Microservice is in the eye of its be^H^Hconsumer; it wouldn't care if two microservices shared a data source. You could have a single weather data warehouse supplying multiple microservices: one giving you the current conditions at a location, another a weekly forecast, yet another some historical snapshot...

@mustaccio overlapping read and write perms

Why is that significant, and what database privileges have to do with being a [micro]service anyway?

Example: a fulfillment database and microservices: order entry; warehouse stock updates; order tracking for clients; KPI reports; etc.

my understanding of microservice architecture is that the data is published to other services via the service itself. thus the database (and indeed the entire backend) is obfuscated away and you can make whatever changes you like without breaking integration as long as the endpoints remain consistent. the requirement though is that the service completely owns its backend and doesn't share it with another service.

One microservice to rule them all

i'm not asserting that's the only possible interpretation of microservice architecture at all. what i'm asking is if you're aware of another approach that conforms to what i've described, could you let me know / link me to a blog post or something?

imagining what it could be though is really what i'm trying to avoid

@McNets oh yea, very much monolith by microservices over here

@PeterVandivier IMHO (as a programmer) there is no reason to build 2 or more microservices that use the same DB or at least the same tables/schemas. If you take a look at SOLID principles, S stands for Single responsibility principle, that means: One object/class/service => One function.

I think if you have different services with some shared conformed data, it might not be worth the performance hit to abstract out the common data, especially if it has to be joined. Therefore both services might return some common data.

Say a service that returns invoices and a service that returns payments, all against the same customers. If there is a need in that service to get customer information or customer configuration, should it be obtained through a direct join or does each service have to call a customer service and join/transform the data appropriately.

Personally, I think the services should never go any lower into the database than procs or views.

That at least gives you one layer to allow you to refactor your DB.

If on top of that they need to go to some other common business layer before they expose their service, that's fine too.

Not popped in for ages. How is everyone?

hey @Philᵀᴹ

@Philᵀᴹ hi, welcome back

hey man

Howdy

Morning. @CadeRoux how's the little one doing?

@bbaird She is doing great!

@Phil not bad - and you?

In unrelated news, the saga of my Thinkpad P52s looks like it's completed a chapter. Like my old W520 - which I got about the time I first started participating in DBA.SE - I've pimped this one out for data warehouse development. After I got the machine I discovered you could expand it to 64GB (the machine is lighter and slimmer than a full-fat P52).

So I got some memory for it and it turned out that one of the modules was a dud, causing a couple of blue screens and then failing a memtest86 check. That was February. After getting a RMA number and sending it back to the vendor, the replacement finally arrived a couple of days ago. Just got around to putting in the machine, and it looks like it's passing the test.