Hmm Im not convinced you'd be able to get the performance required to the DB even with the most exotic of caching/read and write tricks. You could maybe memdb it, but then you need a hefty amount of RAM, which again costs.
Has anyone actually tried to benchmark 10000 "nodes" reading and writing to a single DB on decent commodity hardware, let alone the high end stuff? I don't think it would be very pretty.
Plus, what about the pipe, thats a hefty pipe you'd need to serve up 10000 nodes.
In this scenario, you don't actually have 10000 x the DB load, you don't need 10000 DB writes to commit one transaction, you just need one. So, the load on the DB is equivalent to having 1 node. Reads can be cached and then served and farmed out to the 10000 ports.
In memory traffic is fast, a lot faster than DB traffic, so the load on the server would be high, but not untenable. It would just be like a busy website.
No, you're right that is my bad, you don't need 10000 writes per transaction. Essentially in this instance the 10k ports are the same as accepting 10k connections on the same port, but I still maintain that you would need one hell of a machine to manage, maintain those 10000 connections, ports, whatever.
Plus we are forgetting one critical component in this scenario of yours which has been overlooked here repeatedly. The challenges. You'll be getting 10,000+ of them about every minute, 166 of them a second, and none of them will be the same and they are significant work. You'll have to hit the DB and do the work because you can't cache all the data, plus then the processing and creating the solution proof.
And you still havent acknowledged the pipe cost.