Microservice Design - Many microservices reading from a DB. Antipattern?

Question

I'm working on a system design and feel like I'm doing it wrong.

Situation

I have two services and they each have a bunch of data they each need. Much is overlapping data from overlapping tables. Also, I believe these services will be the sole users of these tables.

Let's say Service A needs T1, T2, T3, T4, and Service B needs T2, T3, T4.

It's been suggested I make 4 microservices who sole purpose is to read those 4 tables. That feels like a "too many microservices" anti-pattern.

My Thoughts

All four tables are roughly in the same business domain, and I'd imagine Service A and Service B would be the sole users of all four tables. So I'm thinking we make a single microservice which gets called for any of the T* data. I think everything can scale happily: the services, microservice, and db.

Is there some tradeoff I'm not seeing? Or reason I should use 4 services? I don't think the query logic will be complex for any of the reads, so the source code could be small even for the single microservice solution.

What am I missing?

Answer 1

The main point of a micro service is that it is independently deployable and scalable. If more than one micro service uses the same database then they are no longer independently deployable and scalable. Furthermore, if one database goes down, multiple services become unavailable, breaking yet another advantage of micro service architecture: resilience.

In your case two services need the same data. In a monolithic application it made sense to use the same database. With micro services you solve this by duplicating data, but only the data necessary for that service. If both services really do use all of the same data in the same business domain, you might actually have just one service, not two. Either that or you should investigate whether or not both services actually use all of the data you think they do.

Answer 2

Many microservices reading from a DB. Antipattern?

No. Certainly not if you manage it correctly. A relational database is fantastic at JOIN'ing data efficiently. You should generally only have one Service writing to a table (or table partition). But reads tend to outnumber writes 10:1.

It's been suggested I make 4 microservices who sole purpose is to read those 4 tables. That feels like a "too many microservices" anti-pattern.

Yes, that is an anti-pattern.

Strictly speaking, Microservices are supposed to "own" data. But that often gets pushed too far - leading to a CRUD layer on top of a database (which is already a CRUD layer). So yes, that's an anti-pattern, because you're duplicating functionality and only adapting the data.

From what you have described, I believe Domain-Driven-Design (DDD) calls this a bounded context.

Some more context

Consider the following scenario where T2 and T3 are "Lookup" tables:

• T1 = ProviderCoverageArea
• T2 = StateLookup
• T3 = CountryLookup
• T4 = CustomerAddress
• Service A = Provider Coverage Management
• Service B = Customer Management

In this case, T2 and T3 could even be considered external to the bounded contexts of Service A, and of Service B separately. If someone tells you that it's "not decoupled" enough, you're not doing software right, that's overengineering. A VIEW in the database is a valid way to maintain a long-term "contract" with CountryLookup for reading/JOIN purposes. And you'll do it in 1/10th of the time with less overhead, better performance, and it will survive 20 years of changes in programming language trends.

About Deployment

Whether you have a single binary to deploy those two services, or two binaries doesn't really matter. You can manage the schema separate to the services and you can upgrade the two services separately, with success and reliability. For some scenarios that capability might be critical.