> To edit a Pin, we read-modify-write the JSON under a MySQL transaction: I've seen a different approach where you keep a version number on the row, do your re

> To edit a Pin, we read-modify-write the JSON under a MySQL transaction: I've seen a different approach where you keep a version number on the row, do your read, modify in memory on the app server, then do your write like this UPDATE db03429.pins SET blob=’<modified blob>’ WHERE local_id=7075733 AND version=53 then look at the result and make sure that it modified one row. If it returned zero rows, you retry (or show a failure to the user, whichever is appropriate for your use case). The reason you'd do this is so you can't ever have the row locked for a long period of time. A lot of people don't think about database scalability so _even if they know_ that the code they're writing runs while a transaction is held open, they don't care that that transaction is blocking anything else that is trying to read the row they're working on. This can lead to row lock bloat over time, which can cause scalability / availability issues as app servers wait longer and longer to get read (or write) locks on all the rows they care about for their current request. This is mitigated a bit if you're requiring / encouraging people to read from slaves instead of master, though.