Dropbox System design
If you are preparing for system design interview, this article would give you a very quick understanding of how Dropbox backend was designed and how it gradually evolved.
An important part of system design is how efficiently you can recognize the scope of improvements as requirement changes, that’s what you would understand in this article.
The humble beginning of Dropbox backend looked something like the diagram below(first version) in mid 2007*.
At this time only founders were the developers with ~0 users. The system had everything running on a single server, like the DB, webservers, storage e.t.c.
As I said, System design interviews are more like judging if you understand the trade-offs between different architectural choices.
So the next question is, what can go wrong with the architecture on the left(first version) ?
- Reliability: the system is not reliable, if the server goes down the system has nothing to back it up quickly.
- Bandwidth: the above system can not support many users.
- Space: this is a dominating problem that founders realized, the server went out of disk space to store any more files.
- Overload: the server quickly got overloaded.