Hello Interview

Partitions provide parallelism; key distribution determines whether you use it. Our Kafka guide covers partitioning, hot partitions and the ordering tradeoffs behind scaling: hellointerview.com/twitter/k…

A more granular key can spread that work. But events that used to share a partition may now be processed independently. You need to decide whether the original ordering guarantee is required before changing the key.

Kafka uses the message key to choose a partition. That's useful when related events need ordering: all events for one game can go to the same partition. It also means a hugely popular game can concentrate work in one place.

Your Kafka cluster has spare capacity, but one partition is drowning in traffic. Adding brokers won't spread a single hot key across them. Look at your partition key.

How each type works underneath, and when adding an index is the wrong move: hellointerview.com/twitter/d…

B-trees, hash indexes and R-trees each answer a different question, and the wrong one is worse than none because you pay the write penalty without the read benefit.

An index is a tradeoff you make on purpose: storage and slower writes in exchange for faster reads. Candidates who add indexes without naming that cost get asked about it.

The full deep dive, including how the internals should shape your own design: youtube.com/watch?v=PuZvF2Ey…

Cursors matter more than they sound. Offset pagination over a live index shows people duplicates and skips.

The parts that actually come up are the ones after the match: how filtering narrows the candidate set, how sorting works without loading every document, and how you paginate a result set that keeps changing underneath you.

Elasticsearch turns up in almost every design that involves search, and most candidates can say inverted index and then stop.

All five, including the three most people never reach for: hellointerview.com/twitter/s…

So replicas are for when the primary's CPU is the bottleneck. Caches are for when the query itself is expensive and staleness is acceptable.

A replica takes load off the primary and gives you the same data a few milliseconds late. A cache takes the query away entirely and gives you sub-millisecond reads of data that may be much older.

Read replicas and Redis are the two everyone names. They are not interchangeable and they do not solve the same problem.

A pure hash is deterministic, so the same URL always yields the same code. You get free deduplication and guessable codes in the same move, which is what the salt is for: youtube.com/watch?v=iUU4O1sW…

Base64 would be shorter but two of its characters break in a URL. A slash is a path separator and a plus sign reads as a space in a query string.

Hash the canonical URL and encode the output in base62. Eight characters gives you 62^8, roughly 218 trillion codes.

Taking the first 8 characters of a URL as its short code collapses linkedin.com/in/evan-king and linkedin.com/in/stefanmai onto the same code. The redirect then has no idea where to send anyone.

Redis shows up in way more than caching. Full deep-dive: hellointerview.com/twitter/t…