This is an overall system design and DBMS question:

If the user books a ticket or an item on a website, how do we solve the issue of confirming a ticket is sold to the user, but the main Database System breaks down, and the secondary DMBS doesn't have that information yet?

Is the most common solution just to not commit the transaction until both the master and slave DBMS has confirmed?


There is no single answer that is always used; there is a tradeoff between consistency, availability, and ability to handle failures. Most databases ensure that the data is stored persistently on disk before reporting that the transaction is confirmed, so even if the main database fails, if it has accepted the data, then the data will be there on disk.

Of course you could avoid committing until both replicas have confirmed, but then the system would not be available if either replica cannot be reached; or you could continue as soon as the master has accepted the data, but then the secondary replica could become out of sync. I suggest learning about the CAP theorem and fundamental tradeoffs in database systems.

There will always be some failures that we cannot or do not prevent through technical means. So, they might be addressed by ad-hoc methods (e.g., the customer could call customer support).

  • $\begingroup$ thank you. about "even if the main database fails, if it has accepted the data, then the data will be there on disk." but what if after the commit, it is a disk failure on the master DBMS, before the slave DBMS can get the data? $\endgroup$ – eulerIdentity Feb 23 at 17:15
  • $\begingroup$ @eulerIdentity, "There will always be some failures that..." $\endgroup$ – D.W. Feb 23 at 22:53
  • $\begingroup$ yes... what if we can make the probability a lot lower (remove the single point of failure)... so if the Master DBMS fails once after 5 years, then if the Secondary can kick in, it can improve the probability of success from failing every 5 years to perhaps failing every 20 or 30 years, if both the Master and Secondary fail at the same time $\endgroup$ – eulerIdentity Feb 25 at 6:05
  • $\begingroup$ @eulerIdentity, I'm not sure what to say. There are multiple possible designs, with different tradeoffs - e.g., regarding likelihood of failure and other properties. $\endgroup$ – D.W. Feb 25 at 6:07
  • $\begingroup$ I mean... that's the total point of having a backup of a computer too. We won't say, "nah, let's not do any backup, because there always can be some failures..." $\endgroup$ – eulerIdentity Feb 25 at 6:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.