Two microservices for read and write to one database table

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.

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.