Two microservices for read and write to one database table

Question

I'm a little bit confused about the microservice best practice approach.

Following scenario:

Massive incoming messages from mqtt devices. A rest api where customers could read the messages (mostly only a part of them).

My idea was, to create one microservice for storing the messages in a database table. And a second microservice with a rest api to read this messages. I want to do this, because of scaling issues. (The incoming storing part needs much more power, than the reading rest api)

I read that the "perfect" microservice should be the only one, who accesses his data in a database. So other microservices should ask for this data, via its API and not on database level. So my approach would be not the perfect one. I see a few options to handle this:

• only one mircroservice, for storing and reading
• making an api in the storing microservice, where the rest microservice could fetch the data.

But all of them, doesn't look good for me.

Whats your opinion?

Regards, Markus

Answer 1

I am going to recommend an approach which to some extent would depend on the answer to the following question:

What is the maximum acceptable time delay from the time when a message is committed to the database to the time the message becomes available for a customer to see it?

If the answer to this question is > 10ms then you could consider using read-write separation - yours would appear to be a good use-case.

Although this would arguably introduce more complexity into your solution, the benefits of this approach would include:

• No contention between database writes and reads
• Writes can be scaled independently.
• Your written data can be stored in relational format
• Customer data can be read in the manner which most simplifies retrieval and display concerns (eg denormalised, aligned with viewmodel)

Applying this to your architecture, even without the use of some kind of durable queuing transport it is still possible but more difficult to implement read-write separation. Rather than capitalise on events you would have to make the entire thing command driven.

The main difference here is that you would need to enforce "transactionability" across your main database write and the subsequent call to the service responsible for updating the read model.

Answer 2

Realistically, unless you are doing something computationally intensive on reading or writing, your database IO will likely be your point of contention. I would strongly consider building your system "perfect", and then running capacity tests to see where the choke points are. Do not forget the words of Donald Knuth: "Premature optimization is the root of all evil".

If you decide that your service needs to be scaled, see if you can scale both reading and writing horizontally (make more instances of the combined service).

If this fails to get you the performance you need, THEN look at much more complex scaling requirements like another answerer has proposed.