A new batch of concert tickets just dropped. You login as fast as you can to the website, and see there are two tickets left. You click the buy button. Once you submit, you are greeted with the message that there are no tickets. What?!

This is an example of the concert ticket company falling victim to non-repeatable reads. Let's take a look at an approximate transaction for buying a ticket.

If two people buy a ticket at the same time, we can run into the following scenario, resulting in the buying experience described earlier.

To solve this, we can use the repeatable read transaction level on our database. This makes it so that the DB will hold read locks on any rows that it returns to the application, and write locks on all rows that it inserts, updates, or deletes. Let's examine the effect of this with the same example from earlier.

Tada! The second user will be put into a queue, while the first user is able to purchase their ticket successfully. This is very similar to what real-world ticketing systems like Ticketmaster do for high-demand presales.