Design Typeahead

It sounds like a search problem. The twist is the timing. The suggestions have to appear between one keystroke and the next, so each request is answered in tens of milliseconds. The list is ranked by what everyone is searching for right now, a moving target. Those two pulls, a read that has to be instant and a ranking that has to stay current, are what make this more than a database query.

Pin the latency budget before drawing anything, because it decides the shape. People type a few characters a second, so there are roughly 150 to 200 milliseconds between keystrokes. Suggestions need to land before the next key press, or the box feels laggy. Aim well under 100 milliseconds end to end, and realistically the server side gets a few tens of milliseconds. That budget rules out doing any real ranking work when the request arrives. There is no time to scan a list of matches and sort them. The answer for a prefix has to be sitting there already, computed ahead of time, so the read is little more than a lookup.

One more thing to pin early. The data is overwhelmingly read. Almost every interaction is a lookup, and the set of completions changes slowly, on the order of how fast search trends move rather than per request. That skew is the gift this design is built to exploit. Because writes are rare relative to reads and can be batched, you can spend real time building a read-optimized structure offline and then serve it cheaply millions of times.

The Adobe angle

Search-as-you-type is all over their products, so they want it solid. The box sits in Acrobat, in Creative Cloud asset and Stock search, in Fonts, across help and support, so the interviewer has shipped this shape and knows where the simple version cracks. The round is practical and rewards a clean skeleton with clear trade-offs over a chase toward the largest imaginable scale. One decision drives everything: the ranking happens offline and the read is a precomputed lookup.