1

In my recent interview, I got the following question:

There are multiple instances of a microservice, each connects to the same relational database (let's say postgres). How can you ensure data consistency and concurrency, if you cannot rely on the database to do it for you?

Generally I'd say that there is no problem with multiple instances using the same database, as the db can handle concurrent connections, even when the services try to update the same table, or same rows. But what I don't understand is what can we do if the database, for some reason, cannot handle concurrency?

texmelex
  • 57
  • 7
  • 1
    Multiple solutions here. From pessimistic locking, to optimistic locking, to a third-instace locking service, inter-process communication, using single/multiple queues, serializing updates with a log table, etc., etc. It's too much of an open question, and the answer depends on the effort (read $$$) you are willing to throw at the problem. – The Impaler Nov 04 '22 at 13:39
  • Honestly, I'd consider that question to be a bit of a red-flag about working there. – Levi Ramsey Nov 05 '22 at 15:03
  • Basically it is architectural decision, we can have multiple instances sharing database. At DB level consistency and concurrency is achieved to certain extent .Application layer should be also designed to address any concurrency like multi thread, asynchronous processing etc – BharathyKannan Nov 07 '22 at 03:35
  • It sounds like they were prompting you to talk about eventual consistency and/or CQRS. Very much an opinion-based question... – Neville Kuyt Nov 08 '22 at 09:47

0 Answers0