title: Database for Shared Nothing Architecture
body: <p>Shared Nothing Architecture seems in vogue due to possibility of massive scalability. Processes share nothing.
  Any non trivial application will have some state. This state ideally should not be in the hardware on which the process is running. Reason being, we want that if the hardware/process crashes, client should simply be able to re-run it in a new process or even a new hardware.
  Where does this state go? Let us try some kind of database.. NoSql Redis, Mongo, or RDBMS Oracle.. anything. Now IMO this is no longer Shared Nothing, since the database becomes the bottleneck.
  Now <a href="https://en.wikipedia.org/wiki/Shared-nothing_architecture" rel="nofollow noreferrer">shared nothing at wikipedia</a> gives a small hint that even the database is not shared by using sharding! My q is.. If there are n number of processes, will there be n number of database instances? I believe each process should run in it's own hardware or hypervisor. So for n number of processes and n number of corresponding databases, there should be 2*n pieces of hardware required (not counting replication needed in databases). No doubt the join query on databases will be expensive, as the wikipedia link states. But the possibility of scaling is unlimited.
  Is my assumption correct? What if, I need to increase number of processes from n to m. So what happend to the n databases. Should I increase to m numbers and do a re-sharding? 
  Now add load balancer with auto-scaling. This means the processes can scale up and down. How do we match the shared nothing databases to these processes now? Thanks.</p>