Client-Server Communication: System Design Interview
2669

Design a RPC based system for Client-Server communication.

  • We have already released thousands of clients(mobile devices) to customers and they cannot be modified.
  • There is a queue between Server & Client, but it works as radio broadcasts. Everybody gets every msg & there is no persistence or ack capabilites in the queue.
  • You can create any number of queues in the system free of cost
  • Write pseudo-code for publish, consume and subscribe methods

This is a design questions which I totally bombed as I was completely clue-less what interviewer was expecting. Looking for ways/ideas in which I could have approached this differently.

Requrements Gathering:
Me: What type of requests are these clients(mobile devices) requesting ?
Interviewer: Lets say they are basic operations(Add/Sub/Mult/Divide)

Me: Since we can create queues free of cost in the system, why not we create one queue per individual client/server commuication
Interviewer: There are already thousands of mobile devices(clients) already in the market. How will they know which queue to subcribe/consume to/from?

Me: How about as part of new software update to these clients(mobile devices) we indicate the client, which queue it has to subscribe to ?
Interviewer: That is doable but it is an extremely difficult task to execute.

We only had 30 mins left in the interview at this point
Interviewer: Lets try to solve one of the biggest issue in the system. Can you tell me what might be the biggest issue plaging the system ?
Me: CPU wastage. Since everybody is receiving every message from server, clients constant poll/get messages from queue which maybe completely irrelavent & client just has to drop it.

Interviewer: How to solve this problem ?
Me: We can setup some registration system, by which client knows whether the response was directed to it or not.
Since IMEI number of mobile devices are unique, clients can send their IMEI number with their request and server also appends IMEI number in each response
Once clients receive the response they can see if the response is for itself or not.

Interviewer: Registration system is fine but it doesnt help resolve our issue. Even with registration client have to poll & get each new msg & only then they can decide whether it is directed to them or not.

At this point I didnt have any idea for reducing the CPU cycle wastages. I spoke about scaling the services which do the actual math operation.
Each separate service for Add/Sub/Mult/Divide. Server would route calls based on incoming request.

This was the final arch diagram:
image

At the end interviewer said the optimal solution would be have open single request queue shared by all clients and dedicated response queue's between server & client, so that client only receive responses intended for itself
I was completely baffled by this solution. If you see in the initial stages I had suggested setting up dedicated queue's both for request & response between server & each client, for which interviewer had suggested it was extremely difficult task to carry out.

It is also possible that I may have mis-understood some part of our conversation, but this is what I remember.

I am looking for suggestions/feedbacks about:

  • Is there a better way to setup queue between client & servers, considering the fact that there are thousands of clients already released to market?
  • How to go about handling such non-standard Sys Design questions? [NOTE: I consider design Twitter, FB, Instagram .... to be standard as there are tons of resources available everyhwere]
Comments (5)