c# - Handling limitations in multithreaded server -

in client-server architecture have few api functions usage need limited. server written in .net c# , running on iis.

until didn't need perform synchronization. code written in way if client send same request multiple times (e.g. create sth request) 1 call end success , others error (because of server code + db structure).

what best way perform such limitations? example want no more 1 call of api method: foo() per user per minute.

i thought synchronizationtable have 1 column unique_text , before computing foo() call i'll write foo{userid}{date}{hh:mm} table. if call end success know there wasn't foo call user in current minute.

i think there better way, in server code, without using db that. of course, there thousands of users calling foo.

to clarify need: think light dictionarymutex.

for example:

private static dictionarymutex foolock = new dictionarymutex();  foolock.lock(user.guid); try {     ... } {     foolock.unlock(user.guid); } 

edit: solution in 1 user cannot call foo twice @ same time sufficient me. "at same time" mean server started handle second call before returning result first call.

note, keeping state in memory in iis worker process opens possibility lose data @ instant in time. worker processes can restart number of reasons.

also, want have 2 web servers high availability. keeping state inside of worker processes makes application no longer clustering-ready. no-go.

web apps should stateless. many reasons that. if can it, don't manage own data structures suggested in question , comments.

depending on how big call volume is, i'd consider these options:

1. sql server. queries extremely simple , easy optimize for. expect 1000s of such queries per seconds per cpu core. can bear lot of load. can use sql express free.
2. a specialized store redis. stack overflow using redis persistent, clustering-enabled cache. idea.
3. a distributed cache, microsoft velocity. or others.

this storage problem rather easy because fits key/value store model well. , data near worthless don't need backup.

i think you're overestimating how costly rate limitation be. web-service doing lot more costly things single update primary key simple table.