Is this a video course?

No. This is an interactive, slide-based learning platform. Each lesson has rich text, animated diagrams, live code editors, and quizzes. You learn by reading, interacting, and doing, not by watching videos passively.

How long do I have access?

Forever. Both pricing tiers are one-time payments with lifetime access. This includes all current 766 lessons and any future content we add.

What level of experience do I need?

None. We start from absolute basics like 'What is latency?' and build up to distributed consensus protocols. The Foundation level assumes zero prior knowledge of system design.

How much does the system design course cost?

7.99 US dollars for lifetime access globally, or 499 Indian rupees for lifetime access in India. One-time payment, no subscription, no hidden fees. 11 lessons are free with no signup required.

What technologies are covered?

Everything from DNS and load balancers to Kubernetes, Kafka, distributed databases, consensus protocols, stream processing, security architecture, and observability. We cover principles and real-world implementations used at Netflix, Google, Amazon, Uber, Stripe, and more.

Is this useful for system design interview preparation?

Yes. The lessons are structured around the exact topics asked in system design interviews at FAANG and top-tier companies. Interactive diagrams help you practice whiteboard-style explanations. Covers everything from URL shortener design to distributed payment systems.

How is this different from ByteByteGo or Educative?

766 interactive lessons (4x more than most competitors), 16 different diagram types that build step by step, real production examples from Netflix, Google, Amazon, Uber, and Stripe, and lifetime access for a one-time payment of $7.99 instead of annual subscriptions costing 100 to 200 dollars per year.

What is a vector database?

A vector database turns text into embeddings, points in a high-dimensional space where similar meaning sits close together, and finds the points nearest to a query. That lets a search for being charged twice match an article on duplicate transactions even though they share no words, which is the retrieval backbone under most LLM features.

Why is brute-force nearest-neighbor search too slow at scale?

Because brute-force search compares the query against every stored vector, so its cost grows linearly with corpus size, reaching about a second per query at a million vectors and roughly 100 seconds at 100 million. It is exact and perfectly fine up to around ten thousand vectors, but past that you need an approximate index.

What is approximate nearest neighbor search, and what is recall?

Approximate nearest neighbor search gives up a sliver of accuracy to skip almost all the comparisons, because you rarely need the exact nearest neighbors, you need them fast. Recall measures the fraction of the true top-k neighbors the search actually found, and production systems tune a knob to live near 95 to 98 percent recall rather than chasing 100.

What is the difference between HNSW, IVF, and PQ?

HNSW builds a layered navigable graph and usually gives the best recall per millisecond, IVF clusters vectors into cells and searches only the cells nearest the query, and PQ is compression that shrinks each vector to under a hundred bytes so a billion can fit in RAM. Reach for HNSW first, and move to IVF or IVFPQ when memory rather than latency is the thing hurting.

Why does filtering break naive vector search, and how is it fixed?

If you fetch the nearest vectors first and apply a metadata filter afterward, most of the nearest may be the wrong category, so you get back far fewer rows than you asked for. A real vector database pushes the predicate into the search so it keeps walking the index until it has enough matches that also pass the filter. In pgvector 0.8 and later this is the iterative-scan setting.

Why does a sharded vector index send every query to every shard?

A key-value store routes a known key to one shard, but a vector query has no key: its nearest neighbors could live on any shard, so the query scatters to all of them, each returns its local top-k, and a merge step re-ranks them into the global top-k. That is why fan-out grows with shard count, the opposite of a key-value store.

Which vector database should I use?

Start with pgvector if you already run Postgres and are under roughly tens of millions of vectors, since reusing one database with plain SQL filtering beats standing up new infrastructure. Move to a managed service like Pinecone or a self-hosted specialist like Qdrant, Weaviate, or Milvus only when a real number forces it, and remember the embedding model and chunking matter more than the engine.

Why is exact (brute-force) nearest-neighbor search impractical for a corpus of 100 million vectors?

It is O(n): it must compare the query against every vector, which is far too slow for a live request, Brute-force search compares the query against every stored vector, so its cost grows linearly with corpus size (O(n)). At 100 million vectors that is roughly 100 seconds per query before you even account for many queries per second, which is why ANN indexes exist.

In the recall/latency trade-off of ANN search, what does 'recall' measure?

The fraction of the true top-k nearest neighbors that the search actually returned, Recall is the fraction of the true nearest neighbors that an approximate search finds. Recall of 0.95 means it returned 95 of the true top 100. ANN indexes trade a little recall for a large gain in speed, and the knob (like ef_search in HNSW) tunes exactly that.

You fetch the top 20 vectors by distance and then apply WHERE category = 'billing', but get back only 2 rows when you needed 5. What is the fix?

Push the filter into the search so it keeps walking the index until enough matches pass the predicate (for example pgvector iterative scans), Post-filtering discards the nearest results that fail the predicate, so a selective filter leaves too few rows. The fix is to evaluate the filter during the search so it keeps pulling candidates until enough pass. In pgvector 0.8 and later that is hnsw.iterative_scan = relaxed_order, or you raise ef_search.

Why must a query fan out to every shard in a sharded vector index, unlike a sharded key-value store?

Because the nearest neighbors of a query could live on any shard, so you cannot route to just one, A key-value store routes a known key to one shard. A vector query has no key; its nearest neighbors could be on any shard, so the query scatters to all shards, each returns its local top-k, and a merge step re-ranks them into the global top-k.

Vector Databases and Approximate Nearest Neighbor Search

Name: System Design Masterclass
Availability: InStock

in Llm Genai Ops

This lesson is part of the AI Engineering course. Unlock the full course, a separate one-time payment, for lifetime access.

One-time payment. Lifetime access. No subscription.

Global

$20/lifetime

One-time payment via PayPal

Get Lifetime Access

5 Foundation lessons free, try before you buy

India Special

India

₹999/lifetime

One-time via UPI, cards, or net banking

Where this shows up in interviews

2 system design questions lean on this idea. Each walks through the full answer.

5 Foundation lessons free, try before you buy

“The interactive diagrams alone are worth way more than the price.”

Anish K., Senior Engineer at a Bengaluru startup

Every ML Platform lesson, Foundation to Advanced

Real architecture diagrams with real tool logos

MLOps, LLMOps, and data engineering in depth

Quizzes with instant feedback

Built and reviewed by senior engineers

Lifetime access, all future content included

The first 5 Foundation lessons of this course are free, no payment needed. Try them now