Microservice Granularity: Should a service ever be broken into smaller services with a shared database?

Question

I'm trying to understand the size of a micro service.

Fake situation: Data is read 1,000,000 times for every write. So when you scale out you generally only care about scaling out for the 'GET' requests, not the POSTs. Should POST and GET be separate deployable applications?

PRO: Spinning up a 'GET' box would be faster and less memory/data overhead (Obviously in the contrived example the difference isn't much, but I'm thinking about things larger scale)

CON: Then there would be two services talking to the same database.

To me this sounds like a logical thing to do, but having microsevices share a database is an anti-pattern. Should I make myself feel better by calling the combination of the two a single micro service, each one separately containers for that endpoint? Should this be avoided?

Answer 1

As stated in the comments above, it indeed depends as it always does.

• Is the stored data fairly static? If so, you could consider a read-only cache for your GET service(s) as an intermediate between the database managed by the POST service and the GET services.

• Is the amount of data relatively small? You could consider using CQRS with event sourcing. The POST service (or command service in the CQRS architecture) creates and sends an event each time data needs to be stored/updated/deleted. Instead of storing the data in its own database, the event containing the data is stored in an event store. The GET service (or query service) maintains its own database instance and listens for the events broadcasted by the command service. The data stored by the query service is tailor-made for the use case that wants to query the data and is populated each time an instance of the query service is started by replaying all events in the event store. An in-memory database could be used when the amount of data is relatively small. Keep in mind you need to accept eventual consistency when using CQRS.

• You could accept the anti-pattern and share the database between the read services and write services. In this case you could also use CQRS and share the database only for the query services.

• Use separate databases and check if replication at db engine level can solve the problem of synchronizing multiple GET instances with the POST instance of the database. CDC (change data capture) might also be an option in these circumstances to synchronize the different databases for the GET services with the one of the POST service. Again you should be aware of possible eventual consistency.

• ...

Hope this brings you some inspiration about possible approaches to solve the problem.

Answer 2

You should not focus on creating an architecture based on microservices.

What you should aim to find is the RIGHT-SIZE-service architecture that suits the technical problem that you are trying to tackle.

Let's not fall into the trap of following strict buzzword definitions as it happened with scrum.