There's no infinitely scalable solution to this problem. There are many
"good-enough" solutions though. I don't know what .Net does, but it
must be
one of those good enough solutions for a range of problems.

Speaking of your program ("every class  has a limited capacity, system
should
not register students in any class more than its capacity"):

The simplest solution is to assume no one else registers the last seat
of
the class while you are also doing that. Well, in many systems the load
is
not that much anyways, and this solution works there.

Another simple solution is to use "serialized read/write" for
reading/writing the rows for this busy table. So basically no one else
can
touch the rows of that table while you're working with it. It puts a
lot of
load on the db of course.

A solution that I like most is to use a good clustered cache. Take a
look at
this: www.tangosol.net/.../thread.jspa
Basically you put a token in the cluster and that token is replicated
to the
other nodes. While there's this token, no other node messes with your
data
:) I've read somewhere that a company called Terracotta provides
essentially
something like this but transparently by intercepting synchronized()
keyword
and injecting some clustered cache byte code there! Very pretty
solution!

But of course even this clever solution is not the ultimate answer. In
a big
cluster, replicating all these little token objects can saturate the
whole
network :)

Tell me: how does google's indexer engine makes sure it doesn't
incorrectly
index a site twice? Is there a hashtable somewhere in memory? You see
they
have 100s of 1000s of servers. You can't really cluster such a thing.
Google
tries to partition its data cleverly, and it works with the big cluster
by
starting big parallel processes (based on MapReduce technique:
http://labs.google.com/papers/mapreduce.html).