The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Approach for system design questions

Dear all,

I'm a grad student in computer science and have got relatively less industry experience (almost nill). In my interviews I get system design questions - I'm looking for approach - how to think and on what lines to move ahead. More than correct answers, I wish to develop my thinking.

Say for example, questions like
1. How will you design Gmail server (that can serve 50 million users simultaneously)

2. How will you design a chat server (like yahoo chat server) - will you thread or forking?

3. Scalability questions.

It would be great to have sample answers to these design questions and moreover tips on directions in which i should think and factors which i should take into consideraiton.

Thank you,
Anurag Laddha.
Anurag Laddha Send private email
Thursday, September 28, 2006
 
 
Do some research on Erlang.

Friday, September 29, 2006
 
 
I'm not sure I follow on the relevance of the Erlang suggestion.  I know it has a unique approach to certain implementation details compared to other implementations available, e.g. concurrency.

The OP seems to be asking how to dissect a complex system into smaller subsystems, which is how complex systems are built.  Would you care to elaborate how learning about a specific language domain is relevant to discussing a broad and generalized problem domain?  I'm genuinely interested because I fail to see the connection.

In the case samples the OP provided it seems like knowledge and understanding of network topology, protocols, and failsafe systems along with how to integrate disparate systems in a heterogeneous environment to behave and appear as a single homogeneous system.  Design patterns could help convey this information to others without getting bogged down in language specific details of things like functional, procedural, modular, generic, object oriented, or even the syntax of "doing" instead of staying focused on the "how" of the design.
Chris Send private email
Friday, September 29, 2006
 
 
1), 2) and 3) You try it and then you learn from your mistakes. That will develop your thinking.
Dino Send private email
Friday, September 29, 2006
 
 
These kinds of questions aren't meant to pull out wholly valid design ideas but instead to demonstrate an understanding of how complex problems are solved through creative thinking.

For example, you asked: "How would you design a server for GMail to handle 50 million users?"

Obviously an environment that needs to support that kind of volume is going require a large number of servers possibly spread over a wide geographic area. So an interesting question becomes, are we talking about building an infrastructure to house an existing application, or is the application part of it? The answers are likely very different.

For example, at first glance, it might seem like you could create a hard limit (say 1,000 accounts per server) and build some kind of routing mechanism to hash out logins to the right server. But Gmail has interconnectivity between accounts---for example, with GMail Chat. At the same time, some accounts are full of data and others empty, some checked constantly and others only once. So such a distribution might be very inefficient.
**

I won't go on but I think I can say with some confidence that this is the style of answer that an interviewer is seeking to the question: "How do you design GMail?".
Robby Slaughter Send private email
Friday, September 29, 2006
 
 
I think a good approach to this sort of thing is to talk about it in increments.  This shows that you are realistic and systematic.

First, identify the major constraints of the problem. Although design is commonly understood to mean how the system will be structured, I think good design is a lot more about how you will adapt the structure of the system to the constraints placed upon it. Constraints are the factors which limit the ability of the system to meet your goals for it.  In your example above, limits on scale-out are excellent candidates for a constraint.  These are the design drivers.

Next, create a design that you can test and experiment with, perhaps with a prototype.  You can use this to drive successive round of improvement, until the resulting design converges on all the constraints placed upon it.

The main thing I'd look for is the practical realization that good design isn't done in one fell swoop.  It's a learning process.  People that give me a description of a final design off the tops of their heads would make me question their abilities...
Josh Send private email
Friday, September 29, 2006
 
 
Dear all,

I wish to thank everyone for their inputs. Suggestions given will surely give some direction to my thinking.

It would be great if someone can explain me with an example - how would experienced people like you all give an answer - lets say how would one design Gmail system - initially to support hunderd thousand users and then in incremental stages, changes that may be required to support 100 million users and now that even Gtalk is integrated with Gmail.

I know it requires both experience and knowledge to design a system and I guess I lack both currently :)

Thanks,
Anurag Laddha.
Anurag Laddha Send private email
Friday, September 29, 2006
 
 
I wouldn't worry so much about experience and knowledge. I know that sounds counterintuitive, but I think there's much more value in being creative and open-minded.

The reason that "experience" and "knowledge" aren't that useful in answering these kinds of questions is that the interviewer isn't really looking for specific ideas that are immediately actionable. Were you a qualified expert in building large scale distributed web applications, you might get off into a side discussion about DNS round-robin or recommend BIG-IP boxes from F5 or discuss your personal experiences setting up failover clustering in SQL Server. But that's precisely the kind of narrow-minded buzzword-laiden junk that doesn't impress interviewers.

Good techniques for answering questions like the one you posed above are:

1) Immediately question the question. "Why ask about going from 100,000 users to 100 million? A more interesting case is going from 1 user to 1,000. Let's talk about that first..."

2) Explore by analogy, even by extreme analogy. "Well,  running a 100 million mailboxes related to the problem of running 100 million search queries, which Google has already solved. So one thought would be to try and translate each possible mail operation into a corresponding search query, and stack the results or the algorthim accordingly." Or more extreme: "That sounds like growing a restaurant chain from 10 locations to 10,000..."

3) Break down the problem into parts. "Gmail certainly has a lot of moving pieces. There's a whole section which is just traditional mail handling on a massive scale. Then there is storage and searching, which Google has pretty well licked. Logging in seems to be done through a common framework, so that needs to be respected. Plus there is the main user interface, with chat integration. Now that we have the main pieces, let's look at each one in turn..."

***

Why don't YOU try to answer your own question about Gmail, or anything else? Maybe that would help in finding out why you are having trouble approaching these kinds of design challenges.
Robby Slaughter Send private email
Saturday, September 30, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz