Design File Search

Dropbox stores a person's documents, spreadsheets, images, and PDFs. At some point that pile gets big enough that scrolling folders stops working, and people just want to type a few words and find the file. The real system behind this is Nautilus, Dropbox's search engine. It was built to serve more than 500 million users across hundreds of billions of documents, with results personalized to each person. This design shows up in senior and machine-learning-adjacent loops rather than every mid-level interview. It is a good one to have ready, because it rewards the two instincts Dropbox cares about most: separating the heavy write-side work from the read path, and getting access control exactly right.

The job sits between a user typing a few words and a ranked list of their files coming back. To do it, the system has to have already read the contents of every file, pulled out searchable text, and folded it into an index, all while files keep changing underneath it. And it has to do the one thing a generic web search never worries about: make absolutely sure a result set never includes a file the searcher is not allowed to see.

The Dropbox angle

The constraint that makes this a Dropbox problem, and not a generic "design search," is that a result must never leak a file the user cannot access, not even its existence. Web search indexes public pages, so ranking is the whole game. File search is private by default and layered with sharing. A file lives in a folder, that folder may be shared with a team, and a link may grant outside access. Any of that can be revoked at any moment. So retrieval is only half the work. Every candidate the index returns has to be checked against who is allowed to see it right now, and the filter has to reflect a permission that changed one second ago.