I'm preparing for system design interviews and while looking at the examples I see sentences like: "because write operation takes a lot of time to process and this keeps server port busy we should split our app server into read and write nodes. This should increase performance of our system". And I can't wrap my head around this decision. Here is the final architecture
We have a web server which redirects a request to either write or read node. And it still waits while write node is processing the request and hence ports are busy. So that means we should have separate web-servers for read and write. And hence we need two domain names: app.com and write-app.com. A subdomain is processed by the same server as the one handling requests to the main domain. So introducing a subdomain like write.app.com is not an option. For this solution we need to buy an additional domain, setup a DNS load balancer, a set of web-servers, maintain two related functionalities (read/write) on different nodes. It seems simpler to keep a single read/write APIs on the same node but have more web-servers and more instances available. This way the system will be less complex.
When it makes sense to split Read and Write APIs to different nodes:
- A more efficient at processing write requests machine. It has more powerful (more expensive) CPUs for faster computing in case write operations are CPU bound instead of IO-bound. And read nodes are less powerful (cheaper) but good enough to query a data from DB, execute presentation logic and send back HTML.
- Write operation is very resource intensive: takes lots of memory, steals CPU time, accesses disk a lot. So all read requests on this server are degraded.
- We have software licensed only for a certain number of nodes and so we isolate machines with this software into separate nodes.
What are your reasons to split an app server into read and write servers?