[aliakhtar]

> I also don't know what you mean by "you express most of these in code". The problem isn't writing a piece of code that expresses that constraint... the problem is doing so without introducing a race condition!

I agree, and this also exposes a weakness of javascript as a backend language. If you use Java/Scala, you have multithreading support and can sync the threads + concurrently verify that an item isn't being purchased more than X times. Which makes this problem solvable even with a NoSQL database. Javascript is single threaded though, which makes this problem a lot harder and I don't know how you'd solve it without an RDBMS with transactional support.

[AlisdairO]

> If you use Java/Scala, you have multithreading support and can sync the threads + concurrently verify that an item isn't being purchased more than X times.

That does cause you to have a hard limit of one application server for the app, which can be a pretty big deal...

[aliakhtar]

No, you could have multiple servers talking to each other via something like ZooKeeper. But individually, each node/server would use multithreading to keep track of its state.

[AlisdairO]

I guess, but that's some monumental hackery to overcome something that works perfectly fine in an RDBMS :-)

[aliakhtar]

Until the time comes when you need to scale out your RDBMS and need to shard it. IMO that's a bigger pain ;).

Plus if you have multiple servers, they will most likely need to pass messages for other things too.

[AlisdairO]

I dunno - you've presumably got to implement code to make sure that other servers get unlocked when your locking app server goes down, for example. Personally I try to avoid implementing ad-hoc distributed systems if I can avoid it. Having to shard is pretty damn crappy, but under the circumstances I'd favour it.

Further, I tend to think that if your application is heavy enough to outgrow a reasonably fat db server with (say) 500+GB of RAM, strategies like reimplementing consistent-db-esque locking in an app server + zookeeper setup are also likely to hit some pretty weird performance issues.

[aliakhtar]

> you've presumably got to implement code to make sure that other servers get unlocked when your locking app server goes down

Don't see why you'd need locking. Node A receives a request to buy an item, A asks nodes B, C, and D to confirm that the item is in stock in each node's internal state. If all give the OK, A lets the purchase go through. If node B goes down, then A just asks C and D. I don't see the need for locking or a master/slave.

> a reasonably fat db server with (say) 500+GB of RAM

You have a single point of failure with a single, monolithic server. If its hd dies, you will be in serious trouble restoring terabytes of db.