Everything in this series so far has quietly run on one index, and you’ve been picturing it as a single thing sitting on a single machine. That picture is fine for learning queries and mappings. It falls apart the moment someone asks the two questions that actually decide whether Elasticsearch stays up in production: how does one index hold a billion documents when no single machine has the RAM or disk for it — and what happens when one of those machines simply dies at 3am?

The answer to both is that Elasticsearch is distributed. It doesn’t keep your index on one box; it spreads the data across many machines and coordinates them so the whole thing looks like one index to you. If you’ve run containers or clusters before — Kubernetes, a database replica set, anything with more than one node — the shape will feel familiar. Four terms, built up from the bottom.

Shards, replicas, nodes, cluster

A primary shard is the unit of scaling. When you create an index, Elasticsearch doesn’t store it as one blob — it splits it into shards. The crucial thing to internalise: each shard is itself a complete, self-contained Lucene index — a full inverted index with its own segments, exactly like the one from the earlier parts of this series. An index isn’t “one Lucene index cut into pieces”; it’s N independent Lucene indices that Elasticsearch presents as one. Split an index into 5 primaries and spread them across 5 machines and you have horizontal scaling: five machines’ worth of RAM, CPU, and disk working one index.

Every document lives in exactly one primary shard. Which one isn’t random — Elasticsearch hashes the document’s id:

shard = hash(_id) % number_of_primaries

That formula is how a search knows where a document is, and (as you’ll see) it’s also the reason one number can never change.

A replica is a copy of a shard. It does two jobs. First, failover: if the node holding a primary dies, Elasticsearch promotes one of that shard’s replicas to be the new primary — no data lost, no downtime for that shard. Second, read scaling: a search for a given shard can be served by the primary or any of its replicas, so more replicas means more machines answering reads in parallel. One hard rule governs placement: a replica is never put on the same node as its primary. A copy that dies with the original is not a copy.

A node is a single Elasticsearch process — one server, one JVM — that holds some shards. A cluster is a set of nodes working together, coordinating which shards (primary and replica) live on which node, and reshuffling them when nodes join or leave. You talk to any node; it routes your request to wherever the data actually is.

Fixed vs flexible

Two settings control this, and they behave completely differently — which one you can change later is the single most important operational fact in this whole article.

✦ One number is carved in stone, the other is a dial

number_of_shards — the count of primaries — is fixed at index creation. You cannot change it later without reindexing into a new index. The reason is the routing formula: hash(_id) % number_of_primaries. Change the divisor and every existing document would now hash to a different shard than the one it’s actually stored in — lookups would miss, and the index would be corrupt. Since ES 7.0 the default is 1 primary shard.

number_of_replicas is the opposite — changeable anytime, live. Dial it up when you need more read capacity or more redundancy; dial it down to reclaim disk. No reindex, no downtime. It’s a runtime knob.

The mental shortcut: decide your primary count carefully once; treat replicas as a slider you adjust forever.

Cluster health colours

Walk through what actually happens when you create an index, because it explains the colour your cluster reports and why a fresh single-node dev box is almost always “yellow.”

PUT /products
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }
}

You’ve asked for 3 primaries and 1 replica of each, so Elasticsearch has 6 shards to place: 3 primaries + 3 replicas. On a 1-node dev laptop it assigns the 3 primaries with no problem — but the 3 replicas have nowhere to go, because a replica can’t sit on the same node as its primary and there’s no second node. Those 3 replicas stay unassigned, and the cluster reports yellow.

Add a second node and the cluster immediately places the 3 replicas there — now all 6 shards are assigned and health goes green. And the payoff: if a node now dies, its shards exist as copies on the other node, so Elasticsearch promotes the surviving replicas to primaries and keeps serving with no data lost.

The shortcut worth memorising: yellow is a redundancy problem, red is a data problem. Yellow means “you’d lose availability if another node failed.” Red means “some of your data is already unreachable right now.” Yellow can wait until morning; red is a page.

The oversharding trap

Now the mistake that new cluster designers make almost universally, because the intuition is so reasonable.

⚠ 'More shards = faster' — the #1 cluster-design mistake

The reasoning goes: shards enable parallelism, so more shards must mean more speed — I’ll create 50 up front to be safe. It bites you two ways.

(1) Every shard has fixed overhead. Remember each shard is a full Lucene index — it costs file handles, heap for its segments and metadata, and a slice of cluster-state bookkeeping, regardless of how little data it holds. Thousands of tiny shards can exhaust the heap and slow the entire cluster even when the total data is small. Common guidance is to aim for tens of GB per shard and to keep the shard count proportional to your heap — not “one shard per anything.”

(2) A search fans out to every shard. A query hits all shards of the index and then merges the results. More shards means more per-query fan-out and more merging; past a point, adding shards makes queries slower, not faster.

And you can’t cheaply undo it, because primaries are fixed — an over-sharded index means a reindex. So shard for the data size and node count you actually have, not “just in case.”

The fluent stance is boring on purpose: with the ES 7.0+ default of 1 primary and small-to-medium data, you often don’t touch the shard count at all until a single shard would grow past the tens-of-GB range.

That’s the architecture. Now the other half of running at scale: getting data in fast, and understanding what “in” even means.

The bulk API — batch your writes

Here’s the scenario this section exists for: you need to sync 5 million rows from Postgres into Elasticsearch. The naive approach is one HTTP request per document — POST /products/_doc/1, then /2, then /3. That’s fine for a handful of documents and catastrophic for volume: each request pays a full network round-trip plus per-request coordination overhead, five million times over. You’ll be waiting for days and hammering the cluster with connection churn.

The bulk API exists precisely for this. POST /_bulk packs many operations — index, create, update, delete — into a single request, amortizing the round-trip and coordination cost across all of them. This isn’t an optimization you reach for occasionally; for loading data it is simply the way. Any real ingest path — the Postgres sync, a reindex, a backfill — runs through bulk.

The format has one quirk that surprises everyone the first time. It’s NDJSON — newline-delimited JSON — and each document takes two lines: an action line describing what to do, then the source line with the document body.

POST /_bulk
{ "index": { "_index": "products", "_id": "1" } }
{ "name": "Widget", "price": 9.99, "in_stock": true }
{ "index": { "_index": "products", "_id": "2" } }
{ "name": "Gadget", "price": 14.50, "in_stock": false }

Two things about that format. The body must end with a trailing newline — the parser uses it as a delimiter, and omitting it is a classic “why is my last document missing?” bug. And the reason for the two-lines-per-doc design is deliberate: Elasticsearch parses the payload line by line rather than loading the whole request as one giant JSON tree, so it can stream a huge batch without holding all of it in memory at once.

Bulk is partial-success — check every item

This is the trap that silently loses data, and it’s worth being blunt about.

⚠ A 200 does not mean 'all indexed'

A bulk request does not succeed or fail as a unit. If document #37 hits a mapping conflict, the other 999 in the batch still index just fine — #37 fails alone. And here’s the part that catches people: the overall HTTP status is still 200, even when individual items failed.

The truth lives in the response body, not the status code. Every bulk response carries an "errors": true flag when any item failed, plus a per-item items array where each entry has its own status and, on failure, an error:

{
  "errors": true,
  "items": [
    { "index": { "_id": "1", "status": 201 } },
    { "index": { "_id": "2", "status": 400,
        "error": { "type": "mapper_parsing_exception" } } }
  ]
}

Treat a 200 as “everything indexed” and you will silently drop documents — a data-loss bug that surfaces weeks later as “some records just aren’t in search.” Production ingest must read errors, walk the per-item results, and log or retry each failure individually.

For the Postgres sync, that means your loader can’t just fire batches and move on. After each _bulk call it inspects response.errors; if true, it pulls the failed ids out of the items array and decides — retry the transient ones, quarantine and log the genuinely malformed ones. “Fire and forget” is how you end up with a search index that’s quietly missing 0.3% of your data.

Refresh, flush, translog — three different things

These three words get used interchangeably in casual conversation, and that’s exactly how people end up confused about durability and visibility. They are three distinct operations, and being precise about them is what separates someone who can reason about Elasticsearch from someone who guesses.

✦ Visibility, crash-safety, and durability are three separate mechanisms

When you index a document it first lands in an in-memory buffer — it is not yet in any searchable segment, so a _search won’t find it.

Refresh = visibility. A refresh takes that buffer and writes it into a new Lucene segment, which initially lives in the OS filesystem cache. Search reads segments, so a document only becomes searchable after a refresh. The default refresh interval is 1 second — and that one-second gap between “indexed” and “searchable” is exactly what “near real-time” means, mechanically. (Note: a direct GET /products/_doc/1bypasses this entirely — it reads the buffer, so get-by-id is real-time even though search is not.)

Translog = crash-safety, immediately. The translog (transaction log) is appended on every write the instant it happens. So if a node crashes after you’ve indexed but before the data reached durable disk segments, Elasticsearch replays the translog on restart and nothing is lost.

Flush = durability. A flush is the separate operation that fsyncs the segments to disk and then trims the translog (its entries are now safely persisted in segments, so they’re no longer needed for replay).

Crisp summary: refresh makes data searchable (in the fs cache); the translog keeps it crash-safe between flushes; flush persists it to disk and trims the log.

The one sentence to never say is “refresh flushes to disk.” It doesn’t — refresh only moves data into a segment in the filesystem cache and makes it searchable; it says nothing about durability. Durability is flush’s job, and crash-safety in the meantime is the translog’s job. Conflate refresh and flush and every reasoning-about-data-loss conversation you have afterward will be subtly wrong.

Tuning a big bulk load

Back to the 5-million-row sync, armed with the write path. Refreshing once per second is great for interactive use, but during a massive load it’s wasteful — you’re building a fresh Lucene segment every second, producing a pile of tiny segments that Elasticsearch then has to merge together later. And every replica has to index every document too, doubling (or more) the write work while the load runs.

The standard recipe is to turn both off during the load and restore them after. Disable auto-refresh by setting refresh_interval to -1, and drop number_of_replicas to 0 so only primaries do the indexing work:

# 1. Before the load: disable refresh, drop replicas.
PUT /products/_settings
{ "index": { "refresh_interval": "-1", "number_of_replicas": 0 } }

# 2. Stream the Postgres rows in batches of ~5000 via _bulk,
#    using the Postgres primary key as _id (Part 2's PK-as-_id).
#    CHECK response.errors on EVERY batch — see the gotcha above.
POST /_bulk
{ "index": { "_index": "products", "_id": "42" } }
{ "name": "Widget", "price": 9.99 }
# ...4999 more documents...

# 3. After the load: restore refresh and replicas, then refresh once.
PUT /products/_settings
{ "index": { "refresh_interval": "1s", "number_of_replicas": 1 } }
POST /products/_refresh

The trade you’re making is explicit: with refresh disabled the newly-loaded documents aren’t searchable until step 3, and with replicas at 0 you have no redundancy during the load. In exchange you get a large throughput gain and a clean set of segments — the “load 10 million documents without melting the cluster” pattern. Restoring replicas afterward lets Elasticsearch copy the finished primaries across nodes in one efficient pass instead of indexing every document twice as it arrives.

Notice how much of this reuses earlier parts: PK-as-_id (Part 2) so re-running the sync updates rather than duplicates, replicas for the redundancy you restore at the end, and refresh for the visibility you deliberately traded away and then bought back.

Where this goes next

You now have the operational half of Elasticsearch: how an index survives scale and machine death, and exactly what happens to a document between “indexed” and “searchable and durable.” The final part, Part 8: design decisions, steps back from mechanics to judgement — when Elasticsearch is the right tool at all, and when reaching for it is a mistake.

If you can explain why a fresh single-node cluster is yellow rather than green, and state the difference between refresh, flush, and the translog without conflating any two of them, you understand how Elasticsearch actually runs — not just how to query it.

Everything so far has answered one question: which documents match? You wrote queries, they filtered and ranked, they handed back a list of hits. Aggregations answer a completely different question — what can I compute across the documents that matched? Counts, averages, groupings, histograms, distributions.

This is the analytics engine of Elasticsearch. It’s the machinery under every Kibana dashboard and the “A” in the reason people run the ELK stack for logs and metrics. And here’s the good news if you already know SQL: aggregations map almost one-to-one onto the GROUP BY and aggregate functions you write every day. You’re not learning a new idea; you’re learning a new syntax for an idea you already have.

Two families

There are two kinds of aggregation, and keeping them straight is most of the battle.

Metric aggregations compute a single number over a set of documents. These are the direct analogs of SQL’s aggregate functions:

stats is a small gift: one aggregation returns the count, min, max, average, and sum together, so you don’t fire five separate ones to describe a column.

Bucket aggregations group documents into buckets — this is GROUP BY. Each bucket is a set of documents that share something, and every bucket carries a doc_count: how many documents fell into it (your COUNT(*) per group).

So terms on a status field gives you one bucket for paid, one for pending, one for cancelled, each with its own doc count — exactly what GROUP BY status produces.

The power move: nesting

Metric and bucket aggregations are useful alone, but the real leverage comes from combining them.

✦ A metric per group is just a metric inside a bucket

Put a metric aggregation inside a bucket aggregation and you get “a number per group” — which is precisely what SELECT category, AVG(price) ... GROUP BY category does. The bucket aggregation carves the documents into groups; the metric runs once per group. Buckets can nest inside buckets too: group by category, then by status within each category, and you’ve written a two-level GROUP BY without a single JOIN. Nesting is the whole toolkit — most real aggregation requests are a bucket with one or more metrics spooned inside it.

The request shape

Aggregations don’t get their own endpoint. They ride on _search, alongside the query. That raises an obvious question: if you only want the grouped numbers, why pay to return documents too?

You don’t. Set "size": 0 to say “I don’t want any hits back — just the aggregation results.” It’s faster (Elasticsearch skips fetching and scoring documents to return) and the answer lands in a separate aggregations block in the response.

Here’s the parallel, side by side. The SQL you’d write:

SELECT category, AVG(price) AS avg_price, COUNT(*) AS n
FROM products
WHERE in_stock = true
GROUP BY category;

And the Elasticsearch request:

GET /products/_search
{
  "size": 0,
  "query": { "term": { "in_stock": true } },
  "aggs": {
    "by_category": {
      "terms": { "field": "category" },
      "aggs": {
        "avg_price": { "avg": { "field": "price" } }
      }
    }
  }
}

Read it against the SQL. The terms aggregation named by_category is your GROUP BY category. The nested avg_pricemetric is your AVG(price). The query is your WHERE. The response mirrors it:

{
  "aggregations": {
    "by_category": {
      "buckets": [
        { "key": "keyboards", "doc_count": 42, "avg_price": { "value": 58.3 } },
        { "key": "mice",      "doc_count": 31, "avg_price": { "value": 24.9 } }
      ]
    }
  }
}

Each entry in by_category.buckets[] is one group: key is the category, doc_count is your COUNT(*), and avg_price.value is your AVG(price). You didn’t need to select the count — the bucket hands it to you for free.

→ The filter runs first — like WHERE before GROUP BY

One twist versus SQL, though it works the way you’d hope: the query runs first, and the aggregations compute only over the documents it matched. That’s the same ordering as WHERE before GROUP BY — you group what survived the filter, not the whole index. Narrow with the query, then aggregate over what’s left.

You can’t aggregate on analyzed text

Now the concept from earlier in this series comes back to collect its debt. Text analysis — the tokenizing, lowercasing, stemming that makes full-text search work — is exactly what makes aggregating on a text field either fail or lie to you.

⚠ A terms agg on a text field either errors or does the wrong thing

It’s tempting to point a terms aggregation straight at a name field and expect one bucket per product name. Two things stop you:

(1) It usually errors. Aggregations and sorting read from a columnar structure called doc_values, built per-document at index time. Analyzed text fields don’t build doc_values by default — their content lives in theinverted index instead. So by default a terms agg on a text field fails, telling you to enable fielddata. Don’t reach for that switch: fielddata loads the field into heap memory and is memory-expensive enough to be a genuine footgun on anything but tiny fields.

(2) Even forced, it buckets the wrong thing. Enable fielddata and the aggregation runs — over the individual analyzed tokens, not the whole value. Aggregate a name field holding "Wireless Keyboard" and you get buckets for wireless, keyboard, bluetooth… the tokenized fragments, never "Wireless Keyboard" as one group. You asked to group by product; you grouped by word.

The fix is the rule from Part 2: aggregate and sort on keyword, numeric, or date fields — never on analyzed text.Those field types build doc_values and store the value whole, exactly one per document, which is what grouping needs.

This is the whole reason dynamic mapping gives a string two fields. When Elasticsearch first sees a string like a product name, it maps it as name (a text field, analyzed for search) and name.keyword (a keyword field, stored whole for aggregating and sorting). So to group by product name, you write:

"terms": { "field": "name.keyword" }

The .keyword sub-field is the one with doc_values and the intact value. Search hits name; analytics hits name.keyword. Same string, two jobs, two field types.

Where this goes next

You’ve now got the load-bearing shape of every aggregation: metrics compute numbers, buckets group documents, nesting gives you a metric per group, size: 0 drops the hits, and you aggregate on keyword/numeric/date fields — never analyzed text. That covers the large majority of real dashboards and reports.

There’s more depth here when you need it, all built on the same nesting idea:

• Sub-aggregations go deeper — bucket inside bucket inside metric, for multi-level breakdowns.

• Pipeline aggregations compute over the output of other aggregations — running totals, moving averages, bucket-to-bucket derivatives.

• cardinality gives you approximate distinct counts (like COUNT(DISTINCT)) cheaply at scale, trading a little accuracy for a lot of memory saved on high-cardinality fields.

But the more pressing question is how any of this runs when your index is spread across many machines. An aggregation like terms has to be computed on each shard and then merged into one answer — and that merge step has consequences for accuracy and cost. That’s Part 7: how Elasticsearch runs across shards and replicas, and what the write path looks like underneath.

If you can say which field type you’d aggregate on for a product-name breakdown and why the text version fails — and why you’d set size: 0 when you only want the numbers — you understand aggregations better than most people copy-pasting dashboard queries.

Part 1 made a claim and then moved on: Elasticsearch returns results ranked, not just matched. A SQL WHERE name LIKE '%keyboard%' gives you rows that match — in whatever order the database felt like. Elasticsearch gives you rows sorted by how well they match, and it attaches a number, the _score, to each one.

This part is how that number gets computed. The engine behind it is BM25 (Best Match 25), the default similarity in modern Elasticsearch. You will never need to write the formula out. What you need are three intuitions — and together they explain almost every “why did that product rank first?” question you’ll ever ask.

Keep a products index in mind the whole way through: each document has a short name and a long description, and you’re building the search box for the store.

Factor 1 — Term Frequency (TF), with diminishing returns

Start with the obvious signal. If someone searches keyboard, a document whose text says “keyboard” five times is probably more about keyboards than one that says it once. That’s term frequency: the more often a query term appears in a document, the higher that document should score.

The naive version of this idea — just count the occurrences — has a nasty failure mode. A page that repeats “keyboard keyboard keyboard keyboard keyboard…” fifty times would bury a genuinely relevant product. Keyword stuffing wins.

BM25 fixes this by making term frequency saturate. Going from 1 occurrence to 2 boosts the score a lot. Going from 2 to 3 boosts it less. By the time you’re going from 20 to 21, the needle barely moves — the curve flattens out toward a ceiling. Each additional mention is worth less than the one before it.

That single design choice is the headline improvement over naive counting: it captures “this term shows up here” without letting a document win by sheer repetition. Presence matters; obsessive repetition doesn’t pay.

Factor 2 — Inverse Document Frequency (IDF): rare terms matter more

Term frequency looks inside one document. The second intuition looks across the whole index, and it’s the one that most changes how rankings feel.

Ask yourself how much a match actually tells you. If a term appears in almost every document in the index, matching it is nearly worthless — it doesn’t distinguish this document from the pile. If a term appears in only a handful of documents, matching it is highly informative: this is one of the few documents that’s about that thing.

BM25 encodes exactly this with inverse document frequency. Common terms get weighted down; rare terms get weighted up. IDF is computed per term, across the index.

Make it concrete. Search wireless mechanical keyboard against your products index. Nearly every product mentions “keyboard,” so matching “keyboard” barely separates the field. Far fewer say “mechanical.” So a document that matches “mechanical” earns much more from that match than a document that only matches “keyboard” — even though both are query words. Rarity is worth more than ubiquity.

Factor 3 — Field-length normalization

The third intuition is about where the match lands. The same term is not equally significant in a 3-word name as it is in a 500-word description.

If “keyboard” appears in a three-word product name, it’s a big fraction of what that field is about — the field is practically declaring itself to be about keyboards. If “keyboard” appears once somewhere in a 500-word description, it’s a footnote among hundreds of other words.

BM25 accounts for this by normalizing for field length: it effectively divides out how long the field is. A match in a short field scores higher than the same match buried in a long one. Short, focused fields punch above their weight — which is usually what you want, since a product’s name is a much stronger relevance signal than a paragraph of marketing copy.

Put them together

Those three factors don’t operate in isolation — BM25 combines them into a single number per matched term, then sums across the query’s terms.

✦ The whole formula, in one sentence

_score ≈ (how often the term appears, saturating) × (how rare the term is across the index) ÷ (how long the field is). Term frequency pushes the score up but flattens out; IDF multiplies rare terms up and common terms down; field length divides it back down. Internalize that one sentence and you can predict rankings before you ever run the query — which is the whole point.

Predicting a ranking — worked example

Let’s use the model to call a ranking in advance. Two documents in your products index:

{ "name": "Mechanical Keyboard" }

{ "name": "Wireless Keyboard Bundle with Keyboard Wrist Rest and Keyboard Cover" }

Call them Doc A and Doc B. Now run this query against the name field:

{
  "query": {
    "match": { "name": "mechanical keyboard" }
  }
}

Doc A ranks higher. Walk through why, factor by factor:

• IDF. The query has two terms. “keyboard” is common across the index, so it’s weighted low. “mechanical” is rarer, so it’s weighted high — and only Doc A matches it at all. That rare, high-weight term goes entirely to Doc A. Doc B collects nothing from the most valuable word in the query.

• Field length. Doc A’s name is two words, so its matches normalize up. Doc B’s name is eleven words, so its matches normalize down — the field is longer, so each match counts for less.

• TF saturation. Doc B repeats “keyboard” three times, which looks like it should help. But term frequency saturates: the second and third “keyboard” add far less than the first. Repetition can’t rescue Doc B, and it certainly can’t outweigh the “mechanical” match it’s missing.

Every factor points the same direction, so Doc A wins comfortably. You don’t have to take that on faith — you can ask Elasticsearch to show its work:

{
  "query": {
    "match": { "name": "mechanical keyboard" }
  },
  "explain": true
}

With "explain": true in the search body, each hit comes back with a breakdown of how its _score was built — the tf, idf, and field-length components for every matched term. When a ranking surprises you, this is the first place to look.

The trap: _score is not an absolute number

Here’s where real bugs come from. The _score is a number, and numbers look comparable, so people treat it like a universal relevance grade. It isn’t. Two wrong assumptions cause most of the pain.

⚠ You cannot threshold _score across queries

Wrong assumption #1: scores are comparable between queries. BM25 scores are not normalized to 0–1 or to any fixed range. A top score of 8.2 in one query and 2.1 in another tells you nothing about which result is “better” in absolute terms — the numbers only order results within a single query’s result set. So a rule like “only show results with _score above 5.0” is a trap: it’s a different, meaningless cutoff for every query.

Wrong assumption #2: a document has a stable score. IDF is computed relative to the current index, so the same document with the same query can score differently as the index’s content changes. (Historically, scores could also differ slightly across shards, since each shard computed IDF from its own local statistics.) _score is a ranking signal for one query against the index as it is right now — not a portable, durable relevance grade.

So what do you do when you genuinely need an absolute or normalized notion of relevance — say, “hide results that aren’t good enough”? You treat it as a separate problem. Options include rescoring the top window with a secondary model, learning-to-rank, or client-side min-max normalization within a result set. Just don’t reach for a raw-score threshold and expect it to mean the same thing tomorrow, or on the next query.

Where this goes next

You now have a mental model that predicts rankings. Everything else in relevance is a way to bend that model on purpose:

• Relevance tuning — boosting one field over another (a match in name should count more than one in description), or reshaping scores entirely with function_score (recency, popularity, price).

• Analyzers — synonyms and stemming from Part 3: Text Analysis decide what counts as a match in the first place, which is upstream of every score BM25 computes.

But the pivot from here is bigger than tuning search. In Part 6: aggregations, we stop asking “which documents match?” and start asking “what do the matching documents tell me in aggregate?” — the move from search engine to analytics engine.

If you can predict which of two products scores higher for a given query — and explain why in terms of rarity, saturation, and field length — you understand BM25. And if you can explain why you must never threshold raw _score across two different queries, you understand its one real trap.

In SQL you ask questions with a WHERE clause: a flat string of ANDs, ORs, and comparisons. In Elasticsearch you ask questions with JSON trees — a structure called the Query DSL, where every node is a query and queries nest inside other queries. If you’re building a search box for a products catalogue, this is the language you’ll live in.

Two things make the DSL click, and this part is about both: which leaf query to use for a given field, and which contextthat query runs in. The first decides whether your terms even match; the second decides whether the match contributes to ranking. Both build directly on text analysis — because whether a query analyzes its input is the difference between finding your documents and finding nothing at all.

The three workhorse queries

Ninety percent of the queries you write are built from three pieces: match, term, and bool. Learn these and the rest is variation.

match — the full-text query

match is what you reach for when you’re searching human-typed words against a text field. Its defining behaviour: it analyzes your search string first, using the same analyzer as the field, then looks for the resulting terms.

{ "query": { "match": { "name": "wireless keyboard" } } }

The string "wireless keyboard" gets analyzed to the terms [wireless, keyboard], and Elasticsearch finds documents whose name field contains those terms. Because it’s full-text, results come back scored — ranked by how well each document matches. A product named “Wireless Keyboard, Compact” scores higher than one that only mentions “wireless” in passing.

term — the exact query

term is the opposite reflex. It does not analyze your input — it looks up the literal value you gave it, byte for byte.

{ "query": { "term": { "status": "shipped" } } }

This finds documents where status is exactly shipped. Use term on the fields that hold exact values: keyword fields, numbers, booleans, and dates. It’s the query for structured, categorical data — the equivalent of WHERE status = 'shipped'.

⚠ term against a text field is a classic miss

Run term on an analyzed text field and you’ll often get zero hits. The field was analyzed at index time ("Wireless Keyboard" became the terms [wireless, keyboard]), but term does not analyze your input — so a search for the literal "Wireless Keyboard" looks for that whole capitalized string as a single term, which was never stored. Rule: term for keyword/numbers/booleans/dates, match for text.

bool — the combiner

Real questions have more than one condition. bool is the query that assembles other queries into AND / OR / NOT logic. It has exactly four clause types, and each one means something specific:

Here’s a bool that combines all four ideas — the words the user typed, some hard constraints, and an exclusion:

{
  "query": {
    "bool": {
      "must": [
        { "match": { "name": "wireless keyboard" } }
      ],
      "filter": [
        { "term":  { "in_stock": true } },
        { "range": { "price": { "lte": 100 } } }
      ],
      "must_not": [
        { "term": { "brand": "Generic" } }
      ]
    }
  }
}

Read it top to bottom: the name must match “wireless keyboard” (and that match drives ranking); the product must be in stock and cost no more than 100; and it must not be brand “Generic”. One tree, four kinds of logic.

Query context vs filter context

Notice that the table above splits the four clauses along a line that has nothing to do with AND/OR/NOT: some clauses score and some don’t. That split is the single most important idea in this article.

Every query in Elasticsearch runs in one of two contexts, and the context — not the query type — decides whether a relevance score is computed.

✦ The question each context asks

Query context asks “how well does this document match?” — it computes a numeric relevance _score. Filter context asks “does this document match, yes or no?” — it computes no score at all, just a boolean include/exclude. Same term query can run in either context; the context is what changes. Put your relevance signals in query context and your hard constraints in filter context, and the DSL starts writing itself.

Query context is used by must and should. It computes the _score — the ranked-results behaviour that makes Elasticsearch a search engine rather than a filter. When you put the user’s typed words in must, you’re saying “rank documents by how well they match this.”

Filter context is used by filter and must_not. It computes no score — just membership. This buys you two things:

• It’s faster. No relevance math runs, so a filter is cheaper than the equivalent scored query.

• It’s cacheable. Elasticsearch caches the set of documents matching a filter. Ask “which documents have in_stock: true?” once, and the answer is remembered — every later query that reuses that filter is near-instant, because the set is already computed.

The rule of thumb falls straight out of this. Hard constraints you don’t want influencing the ranking — status = shipped, price <= 100, in_stock = true — belong in filter context. The words the user actually typed, the ones that should decide what ranks first — belong in must (or should). Ranking signals get scored; gatekeeping conditions don’t.

From SQL to bool

Put it all together with a concrete translation. Here’s the question in SQL — find in-stock wireless keyboards under 100, excluding a house brand, ordered by how well they match:

SELECT *
FROM products
WHERE description LIKE '%wireless keyboard%'
  AND in_stock = true
  AND price <= 100
  AND brand <> 'Generic'
ORDER BY <relevance>;

That last line is the tell: a relational engine has no native notion of “order by relevance.” LIKE either matches or it doesn’t — there’s no built-in score for how well a row matched. You’d have to bolt on your own ranking. In Elasticsearch, relevance ranking is the default, and the idiomatic translation makes the split explicit:

{
  "query": {
    "bool": {
      "must": [
        { "match": { "description": "wireless keyboard" } }
      ],
      "filter": [
        { "term":  { "in_stock": true } },
        { "range": { "price": { "lte": 100 } } }
      ],
      "must_not": [
        { "term": { "brand": "Generic" } }
      ]
    }
  }
}

The must clause drives ranking: results come back ordered by how well description matched “wireless keyboard”. The filter clauses narrow the set — in stock, under 100 — without disturbing that ranking, and they’re cached for the next query. The must_not excludes the house brand, also without scoring. Each condition sits in the context that matches its job.

The “just put everything in must” trap

Once you know must means AND, it’s tempting to pour every condition into it: match the description, must the in_stock: true, must the price range, done. It returns the right documents — so what’s wrong with it?

⚠ Everything in must is a performance and correctness smell

Putting a hard constraint like in_stock: true in must goes wrong three ways. (1) Wasted work: must runs in query context, so Elasticsearch computes a relevance score for a plain true/false condition — scoring math that means nothing. (2) No caching: query context doesn’t use the filter cache, so a condition you apply on every search gets recomputed every single time, instead of being answered from a cached set. (3) Skewed ranking: the constraint’s score contributes to _score, so a pure gatekeeping condition subtly reorders your results for no good reason. The fluent move is the split from earlier — query context for what to rank by, filter context for what must be true.

The fix is always the same edit: take the conditions that are hard constraints and move them from must to filter. Same documents come back, but faster, cacheable, and with ranking that reflects only the signals you actually meant to rank by.

Where this goes next

You now know which clause a condition belongs in and why. What you haven’t seen is how the must and should scores are actually computed — where the number in _score comes from when a match query ranks one document above another. That’s the algorithm behind relevance, called BM25, and it’s the subject of Part 5. Once you understand how scoring works, the choice between query and filter context stops being a rule of thumb and becomes an obvious consequence.

If you can look at any condition in a query and say instantly which bool clause it belongs in — and whether it should shape the ranking or merely gate the results — you understand the Query DSL better than most people shipping search to production.

Part 1 gave you the load-bearing idea: an inverted index maps terms to the document IDs that contain them. Search a term, get back the docs — fast, because the lookup is a dictionary hit, not a scan.

But that skipped a question. Your product catalog is full of messy strings — "Wireless Keyboards, Running FAST!" — with mixed case, commas, exclamation marks, plurals. The inverted index doesn’t store that. It stores clean terms. So what turns the string a user typed into the terms that actually go in the index?

That process is analysis, and the thing that performs it is an analyzer. Understanding the analyzer is the single biggest step toward reasoning about Elasticsearch search behaviour — including the text vs keyword rule you met in Part 2, which turns out to be nothing more than two different analyzers running on the same string.

The analyzer pipeline

An analyzer is a pipeline with three stages, always in this order:

raw text → [character filters] → [tokenizer] → [token filters] → terms

Each stage has a clear job.

Character filters (0 or more) operate on the raw string, before anything is split up. They add, remove, or rewrite characters. The classic example is the html_strip filter turning <b>hi</b> into hi. Most fields use none at all — this stage is often empty.

Tokenizer (exactly one) splits the string into individual tokens. This is the heart of the pipeline, and every analyzer has exactly one. The standard tokenizer breaks on whitespace and punctuation:

"Wireless Keyboards, Running FAST!" → [Wireless, Keyboards, Running, FAST]

The comma and exclamation mark are gone; they were separators, not content.

Token filters (0 or more) transform the token stream that comes out of the tokenizer. They run in sequence, each one seeing the output of the last. Common filters:

• lowercase — [Wireless, Keyboards, Running, FAST] → [wireless, keyboards, running, fast]

• stemming — reduces words to their root: keyboards → keyboard, running → run

• stop-words — drops high-frequency noise words like the, a, is

So the terms that land in your inverted index are the output of the whole pipeline, not the words you typed.

→ The default standard analyzer does NOT stem

This is the part almost everyone gets wrong at first. The default analyzer — called standard — lowercases and splits on punctuation and whitespace, but it does not stem. Run "Wireless Keyboards, Running FAST!" through it and you get [wireless, keyboards, running, fast] — plurals kept, running stillrunning. Stemming is a separate token filter that the standard analyzer simply doesn’t include. To get it, you choose a different analyzer, such as english. Keep this distinction sharp; two of the gotchas below fall straight out of it.

Analysis runs at BOTH index time and query time

Here is the idea that everything else in this article depends on. Analysis doesn’t happen only when you store data. It happens twice — once on the way in, once on the way out — and it has to.

At index time, when you store a document, Elasticsearch runs each text field’s value through that field’s analyzer. The resulting terms are what get written into the inverted index. The original string is kept separately (in _source), but it is notwhat you search against.

At query time, a full-text query like match takes the string you searched for and runs it through the same analyzer, before doing any lookup. Only then does it go to the inverted index to find matching terms.

✦ Both sides normalize, and meet in the middle

Suppose you index "Keyboard". The standard analyzer lowercases it, so the inverted index holds the term keyboard. Now a user searches "Keyboard" with a capital K. If the query text went to the index raw, it would look for Keyboard, find no such term, and return nothing — even though the document is right there. It works because the match query runs your search string through the same analyzer, turning Keyboard into keyboard, which does exist. Index-time analysis and query-time analysis normalize both sides to the same form so they can meet in the middle. That symmetry is the whole trick.

The corollary is where the pain lives: if the index-time analyzer and the query-time analyzer disagree, the two sides normalize to different forms and never meet. You get zero hits and no error — the query is valid, the field exists, the document exists, and yet nothing matches. It is one of the most confusing situations in Elasticsearch precisely because nothing looks broken. Keeping “same analyzer, both times” in your head is what saves you here.

Watch it happen: the _analyze API

You don’t have to guess what an analyzer produces — Elasticsearch will show you. The _analyze API runs any analyzer against any text and hands back the exact terms.

POST /_analyze
{
  "analyzer": "standard",
  "text": "Wireless Keyboards, Running FAST!"
}

The response contains four tokens: wireless, keyboards, running, fast. Lowercased, punctuation stripped, and — note again — not stemmed. keyboards stays plural; running stays running. This is precisely what a text field does to its contents at index time.

Now try the keyword analyzer on the same string:

POST /_analyze
{
  "analyzer": "keyword",
  "text": "Wireless Keyboards, Running FAST!"
}

You get back a single token: Wireless Keyboards, Running FAST! — the entire string, verbatim, untouched. The keyword analyzer effectively does no tokenization at all; it treats the whole input as one indivisible term, preserving case and punctuation.

That contrast is the answer to the text vs keyword question from Part 2:

• A text field runs the standard analyzer → many small, normalized terms. Great for match (full-text search across words), useless for exact equality (there’s no single term equal to the original string).

• A keyword field runs the keyword analyzer → exactly one term, the string verbatim. Perfect for term queries, filters, aggregations, and sorting, where you need the value as a whole, exact unit.

So the rule you learned as “use text for search, keyword for exact match” was never really about two field types. It’s about two analyzers applied to the same string — one that shatters it into normalized pieces, one that keeps it whole.

Gotcha 1: term does NO analysis

Now the pipeline pays off by explaining a bug that traps nearly everyone.

Index "Wireless Keyboard" into a text field. The standard analyzer runs, and the inverted index holds the terms [wireless, keyboard] — lowercased and split. So far so good. Now search for it exactly:

{ "term": { "name": "Wireless Keyboard" } }

Zero hits. No error.

⚠ term bypasses analysis entirely

The critical thing to understand: a term query does not analyze its input. It doesn’t lowercase, doesn’t split — it takes your literal string "Wireless Keyboard" (capital W, capital K, the space in the middle) and looks for that exact term in the inverted index. But the index never held "Wireless Keyboard". Analysis shattered it into wireless and keyboard at index time. There is no single term equal to the whole phrase, so the lookup fails silently. The precise framing matters: this isn’t “the query used a different analyzer.” It’s no analysis at all, run against a field that was stored with analysis — a mismatch by omission. Rule of thumb: use match(analyzed) on text fields, and term (not analyzed) on keyword fields. We formalize match vs term in Part 4.

Gotcha 2: the standard analyzer doesn’t stem

The second trap comes straight from the “no stemming by default” fact.

You have a text field storing the word "box". Under the default standard analyzer, the indexed term is box. A user searches for the plural:

{ "match": { "name": "boxes" } }

You might expect a hit — surely Elasticsearch knows boxes is just box? It doesn’t, not by default.

⚠ Plurals don't match without a stemming analyzer

The match query analyzes "boxes" with the field’s analyzer. Under the default standard analyzer, boxesstays boxes — no stemming — so the query looks for the term boxes. The stored term is box. Different terms, no match. To make singular and plural interchange, you need a stemming analyzer such as english, which reduces both box (at index time) and boxes (at query time) to the same root box — and now they meet. The lesson: don’t assume the default stems. If "keyboards" failing to find "keyboard" surprises you, this is why.

A three-tier way to think about matching

Pulling the threads together, whether a search matches comes down to three moving parts lining up:

1. The stored terms are produced by the field’s analyzer at index time.

2. A match query re-analyzes your query string with that same analyzer, so both sides land in the same normalized form.

3. A term query bypasses analysis entirely and looks up your string as a literal.

Getting a hit is a matter of choosing the query type that lines up with how the field was stored. match on a text field: both sides analyzed the same way — they meet. term on a keyword field: the field stored the value verbatim, and term looks it up verbatim — they meet. Cross the wires — term on a text field, or a search that assumes stemming that isn’t there — and you get the silent zero-hit result.

Where this goes next

Everything downstream builds on this pipeline:

• The Query DSL (Part 4) formalizes the match vs term distinction you just met, along with the rest of the query and filter vocabulary. With the analyzer model in hand, those queries stop being magic and become predictable.

• Aggregations (Part 6) lean on keyword fields for exactly the reason this article explains: aggregating and sorting need one exact term per value, which is what the keyword analyzer gives you and the standard analyzer destroys.

If you can predict when a term query will return nothing — and explain why a search for "keyboards" may fail to find a document containing "keyboard" — you understand Elasticsearch text matching better than most people who query it every day.

In Part 1 we drew the rough equivalence: an index is roughly a table, and a document is roughly a row. That gets you oriented, but it dodges the question a backend engineer asks next. When you send Elasticsearch a lump of JSON, how does it know that name is searchable text, price is a number you can sort and filter on ranges, and created_at is a date it can bucket by month? A relational database knows because you wrote CREATE TABLE first. Elasticsearch knows because of the mapping — and the twist is that it will happily write that mapping for you, from the first document you send, whether you meant it to or not.

Throughout this part we’ll keep one concrete scenario in mind: a products index, a catalog synced out of a Postgres table that is your source of truth. Everything — the field types, the CRUD calls, the sync strategy — hangs off that.

The mapping is the schema

A mapping is the definition of each field in an index: its name, its type, and how Elasticsearch indexes it. It is the schema. The reason it feels invisible is that you rarely write it by hand — but it is always there, and you can read it back at any time.

The mapping’s real job is to turn raw JSON into the right internal structures. Text destined for full-text search goes into an inverted index (the term-to-document map we met in Part 1). Numbers and dates go into structures optimised for range queries and sorting. Booleans, keywords, geo-points — each type has machinery behind it. The mapping is what routes a field to the correct machinery.

Here are the field types you’ll reach for most, with the SQL analogy each one maps to:

Most of these behave the way your SQL intuition expects. The one distinction that trips up every newcomer — and the one worth burning into memory — is text vs keyword.

Take the string "Wireless Keyboard". Map it as text and Elasticsearch analyses it: it breaks the string into terms, lowercases them, and stores [wireless, keyboard] in the inverted index. That’s exactly what you want for search — a user typing “wireless” finds the product — but it’s useless for exact work. You can’t reliably group by it, sort by it, or match the whole phrase as one atomic value, because the original string was shredded into pieces.

Map that same string as keyword and Elasticsearch stores it as one exact token: "Wireless Keyboard", untouched, case and spaces intact. Now it’s perfect for filters (status = "shipped"), for aggregations (count products per brand), and for sorting — but you can’t do partial full-text search on it. Searching “wireless” will not match "Wireless Keyboard", because as far as the keyword field is concerned, the only term that exists is the whole string.

✦ text vs keyword is just two analyzers on one string

It looks like two different data types, but underneath it’s the same string run through two different analyzers. text uses an analyzer that splits and lowercases into searchable terms; keyword uses an analyzer that does nothing at all — it keeps the string whole as a single term. Same input, different processing, and every behavioural difference (searchable vs groupable, partial vs exact) falls out of that one choice. We unpack how analysis actually works in Part 3; for now, hold the reframe: not two types, two treatments.

Dynamic vs explicit mapping

There are two ways a field ends up in the mapping.

Dynamic mapping is the default, and it’s the source of that “invisible schema” feeling. Index a document into an index that has no mapping for a field, and Elasticsearch guesses the type from the value in front of it. It’s CREATE TABLE happening automatically from your first INSERT — you never wrote the schema, but a schema got written.

Watch it happen. Index one product, then read the mapping back:

POST /products/_doc/1
{
  "name": "Wireless Keyboard",
  "sku": "MX-01",
  "price": 99.99,
  "in_stock": true,
  "created_at": "2026-07-30T10:00:00Z"
}

GET /products/_mapping

Elasticsearch infers: price → float, in_stock → boolean, created_at → date. And the strings? This is the detail that surprises people: a dynamically-mapped string becomes two fields at once — a text field and a keyword sub-field:

{
  "name": {
    "type": "text",
    "fields": {
      "keyword": { "type": "keyword", "ignore_above": 256 }
    }
  }
}

So name is full-text searchable and name.keyword is available for filtering, sorting, and aggregations. That’s genuinely convenient — you get both behaviours for free without deciding anything. The cost is that you now store every string twice, and you’ve let Elasticsearch guess types for fields you may care about deeply.

Explicit mapping is you taking the wheel. You PUT the index with the mapping spelled out before any data arrives:

PUT /products
{
  "mappings": {
    "properties": {
      "name":       { "type": "text" },
      "sku":        { "type": "keyword" },
      "price":      { "type": "scaled_float", "scaling_factor": 100 },
      "in_stock":   { "type": "boolean" },
      "created_at": { "type": "date" }
    }
  }
}

Every choice here is deliberate. name is text because you search it. price is scaled_float (a float stored as a scaled integer — a tidy fit for money) and could equally be float. And sku is keyword, not text, because you will only ever filter it exactly — sku = "MX-01" — and never run a full-text search over it. A SKU has no words to analyse; treating it as keyword keeps it exact, cheap, and aggregatable. That’s a design decision, made once, on purpose, rather than left to a guess.

You can’t change a field’s type

Explicit mapping isn’t just tidiness. It’s insurance against a limitation that catches people badly.

⚠ Field types are set for the life of the index

Once a field is mapped in an index, you cannot change its type. Suppose the first document your sync job ever sent had "price": "99.99" — a string, because someone forgot to cast it. Dynamic mapping maps price as text forever. You cannot later flip it to float. Range queries and numeric sorts on price are now broken, and no PUT will fix the existing field. The only cure is to create a new index with the correct mapping and reindex the data into it (Elasticsearch has a _reindex API for exactly this). This is the whole argument for explicit mappings on anything you care about — a wrong first guess is expensive to undo.

Two clarifications, because this is easy to over-read. You can add brand-new fields to an existing index at any time — send a document with a field nobody’s seen before and it gets mapped on the spot. What you can’t do is change the type of a field that already exists. Adding is free; mutating is not.

CRUD over REST — and a twist

Every document lives at a predictable address: /<index>/_doc/<id>. Think of the trio — index, _doc, id — as a primary key scoped to a table. The index picks the “table”, the id is the key within it.

Create comes in two flavours, and the difference matters more than it looks.

# You supply the id → create-or-replace, idempotent
PUT /products/_doc/1
{ "name": "Wireless Keyboard", "sku": "MX-01", "price": 99.99 }

# No id → Elasticsearch generates one → a NEW document every call
POST /products/_doc
{ "name": "Wireless Keyboard", "sku": "MX-01", "price": 99.99 }

Run the PUT three times and you still have one document (id 1), each call overwriting the last. Run the POST three times and you have three documents with three random ids. Hold that thought — it comes back to bite in a moment.

A note on vocabulary while we’re here: Elasticsearch uses “index” as a verb. To index a document means to store it. It’s an unfortunate collision with “index” the noun (the table-like container), and reading the docs is smoother once you know both meanings are in play.

Read by id is a GET:

GET /products/_doc/1

And this call has a property that will save you real debugging time: GET by id is real-time. It reads from the in-memory buffer, so it sees a document the instant it’s written — it is not subject to the ~1-second refresh delay we flagged in Part 1. That “I just indexed it and I can’t find it!” moment only bites _search, which waits for a refresh before a new document becomes visible. Fetch the same document by its id and it’s there immediately. If you can GET it but _search can’t find it yet, you’re not losing data — you’re waiting on a refresh.

Update is a partial patch:

POST /products/_update/1
{ "doc": { "price": 89.99 } }

You send only the changed fields; Elasticsearch merges them into the existing document. (What actually happens underneath is more interesting than “merge” — see the next section.)

Delete is what you’d guess:

DELETE /products/_doc/1

And running through all of it is a _version number that increments on every write to a document. That’s your handle for optimistic concurrency: read a document, note its _seq_no and _primary_term, and send them back with if_seq_no / if_primary_term on your write. If someone else changed the document in between, your write is rejected instead of silently clobbering theirs — exactly like an optimistic-lock version column in a relational table.

Documents are immutable underneath

Here’s the mechanical truth behind that “update” call, and it explains a surprising amount of Elasticsearch’s behaviour.

The inverted index lives in Lucene segments — files on disk — and those segments cannot be modified in place. Once written, a segment is immutable. So there is no such thing as editing a document where it sits. An “update” is really a small dance:

1. Fetch the current document.

2. Apply your changes in memory to build the new full document.

3. Re-index the entire new document as a fresh one.

4. Mark the old version as deleted (a tombstone; the space is reclaimed later during segment merges).

✦ Every update is a delete-and-reinsert

There is no in-place edit anywhere in Elasticsearch. Changing one field of a large document rewrites the whole document and tombstones the old copy. This is why Elasticsearch is a poor fit for heavy-update workloads — a counter you bump thousands of times a second, say — where each tiny change forces a full re-index. It’s built to index once and read many, not to churn. We come back to this design point in Part 8 when we talk about what Elasticsearch is and isn’t for.

The PUT-vs-POST trap

Now the two Create flavours collide with the real world, and the result is a classic production mess.

⚠ POST /_doc silently fills your index with duplicates

POST /products/_doc (no id) run three times creates three documents — Elasticsearch mints a fresh id each call. PUT /products/_doc/1 run three times leaves one document, because you named the id and each call overwrites the last. When you’re syncing from Postgres, this is the whole ballgame: use PUT with your database’s primary key as the Elasticsearch id. Then re-syncing a row — because a nightly job reran, or a change-data-capture event replayed — updates the same document in place instead of spawning a copy. Reach for POST in a sync loop and every replay quietly doubles your data, with no error to warn you. The catalog just slowly fills with dupes until someone notices the counts don’t match Postgres.

The rule that falls out of this is short: let your source of truth own the id. If a product is row 4217 in Postgres, it’s document 4217 in Elasticsearch. Idempotent sync, no duplicates, and re-running the sync is always safe.

Where this goes next

We keep circling one unanswered question: what does “analysed” actually mean? We’ve said text gets split and lowercased into terms while keyword is left whole, and that this single choice decides everything about how a field behaves. That’s the promise Part 3 pays off.

How Elasticsearch reads text opens up the analyzer: how a string becomes tokens, what the standard analyzer does to your product names, and why the same query text has to go through the same analysis as the indexed text for a match to happen. It’s the why underneath the text-vs-keyword rule you just learned to apply.

If you can explain why you PUT with the Postgres id instead of POST, and why a wrong first-guess type means a full reindex rather than an ALTER TABLE, you already understand how Elasticsearch shapes your data better than most people who ship to it daily.

Most people meet Elasticsearch as one of two things: “the search box” behind a site’s search bar, or “a fast JSON store” they can throw documents at. Both are true, and both hide the one idea that makes the whole system click.

Here’s the sentence to hold onto: Elasticsearch is a distributed document store built around an inverted index. Two ideas live in there. First, it stores JSON documents, and an index is a collection of similar documents — roughly a SQL table. Second, the inverted index is the data structure that makes search fast. Almost everything Elasticsearch is good at, and almost everything it’s bad at, falls out of that second idea.

We’ll hang every example on something you already know: a products table in Postgres for an e-commerce store, and the copy of it you sync into Elasticsearch for search.

The inverted index — the whole trick

Start with how a relational database thinks. Postgres stores your products data row by row. Each row is a product: its name, its description, its price, sitting together on disk. That layout is perfect for “give me the row with id = 42” or “sum the prices” — but it’s the wrong shape for text search.

Ask Postgres this:

SELECT * FROM products WHERE description LIKE '%wireless%';

To answer it, the database has to walk every row and check whether the text contains that substring. It’s a full scan, it can’t use a normal B-tree index, and it only gets slower as your catalog grows. Worse, it’s doing dumb substring matching — it has no idea that wireless is a word.

An inverted index flips the problem inside out. When Elasticsearch indexes a document, it doesn’t just store the text — it breaks the text into terms and builds a map from each term to the list of document IDs that contain it. For a handful of product descriptions, that map might look like:

wireless  →  [doc1, doc7, doc42]
keyboard  →  [doc1, doc9]
mechanical →  [doc9, doc42]
mouse     →  [doc7]

Now “find documents containing wireless” is not a scan at all. It’s a single dictionary lookup — you go straight to the wireless row and read off [doc1, doc7, doc42]. It’s the same trick as the index at the back of a textbook: you don’t read every page looking for a word, you look the word up and it tells you the pages.

That’s the whole idea. The name even says it: a normal database maps document → its words; an inverted index maps word → its documents. Inverting that relationship is what turns text search from a scan into a lookup.

✦ Why search comes back ranked, not yes/no

The inverted index doesn’t just tell you which documents contain a term — it tracks how often and where, across the whole collection. So Elasticsearch can score each matching document and return them ordered by relevance, not as a flat yes/no match. That’s the deeper reason it beats LIKE: a LIKE query can only say “this row matches or it doesn’t.” An inverted index can say “these 50 documents match, and here’s the best one first.” Ranking isn’t a feature bolted on top of search — it falls straight out of the data structure.

From SQL to Elasticsearch — a worked example

Let’s make it concrete. In Postgres you’d define the table and search it like this:

CREATE TABLE products (
  id          SERIAL PRIMARY KEY,
  name        TEXT,
  description TEXT,
  price       NUMERIC
);

SELECT * FROM products
WHERE description LIKE '%wireless keyboard%';

Two problems with that query, both baked into the row-by-row model. It can’t use a normal B-tree index, so it scans. And the match is literal: a description that says “wireless keyboards” (plural) or “wireless mechanical keyboard” (words apart) won’t match %wireless keyboard% at all. You’re matching characters, not meaning.

Now the Elasticsearch version. You index a document with an HTTP request:

POST /products/_doc
{
  "name": "Wireless Keyboard",
  "description": "wireless keyboard",
  "price": 49.99
}

And you search it with the Query DSL, a JSON body:

GET /products/_search
{
  "query": {
    "match": {
      "description": "wireless keyboard"
    }
  }
}

At index time, Elasticsearch tokenized "wireless keyboard" into the terms [wireless, keyboard] and added both to the inverted index. So the search becomes two fast lookups — one for wireless, one for keyboard — and the results come back scored. A product whose description contains both words ranks above one that only has wireless. You didn’t ask for that ordering; the index gave it to you.

It helps to keep a rough translation table in your head. The mapping is approximate, not exact — the concepts don’t line up one-for-one — but it’s enough to stop feeling lost:

Notice that “table” and “database” both land near “index” — that’s one of the places the analogy strains, and we’ll untangle it in later parts. For now, the one row that matters most is the last one: a SQL WHERE is a filter that a row either passes or fails, while a Query DSL match is a ranked question. Same job, different worldview.

What Elasticsearch is not

Here’s where beginners get burned. Once you see how fast and flexible Elasticsearch is, the temptation is enormous: “This is just a better database. I’ll make it my primary store and drop Postgres.”

Don’t. Elasticsearch is a search and analytics engine, not a transactional database, and the differences are not cosmetic:

• No ACID transactions. You can’t wrap a group of writes in a transaction and get all-or-nothing guarantees across documents.

• No SQL-style joins. There’s no general JOIN between indices the way you’d join tables. You model around that, not with it.

• It’s near real-time, not real-time. A document you just indexed isn’t searchable immediately — it becomes visible only after the index refreshes, which by default happens about once a second. That ~1 second gap is fine for search; it’s a disaster for “read your own write” transactional flows.

Historically, Elasticsearch also made deliberate trade-offs — giving up some consistency and durability guarantees in exchange for speed and horizontal scale. It was built to search and aggregate enormous piles of data quickly, not to be the ledger you bet the business on.

⚠ 'It's just a faster database, so replace Postgres with it'

This is the number one beginner mistake, and it fails in production in the worst way: quietly. You move your products into Elasticsearch as the only store, and for a while it works. Then a checkout needs an atomic multi-row update and there’s no transaction to give it. Then a user updates their profile and doesn’t see the change on the next page load, because the index hadn’t refreshed yet. Then you need to join orders to customers and there’s no join. None of these are bugs — they’re the engine behaving exactly as designed. Elasticsearch didn’t fail to be a good database; it was never trying to be one.

So what’s the right shape? The standard architecture is boringly reliable: keep the source of truth in a real database — Postgres or MySQL — and sync a copy into Elasticsearch for search and analytics. Writes go to Postgres, where you get transactions, joins, and durability. A pipeline mirrors the relevant data into Elasticsearch, where you get fast, ranked, full-text search over it.

Elasticsearch complements your database. It rarely replaces it. When you feel the urge to make it your only store, that urge is the bug.

Where this goes next

Everything above is the foundation. Once “distributed document store built around an inverted index” is second nature, the rest of Elasticsearch reads as consequences of that one idea rather than a pile of features to memorize, these posts are in the queue:

• Mappings & field types — how Elasticsearch knows a field is searchable text versus a number, a date, or an exact keyword, and why that decision shapes everything downstream.

• Text analysis — the exact process that turns a string like "Wireless Keyboards!" into terms such as [wireless, keyboards], including lowercasing and stripping punctuation — and why matching a plural to its singular takes more than the default analyzer.

• The Query DSL — the JSON language for asking questions, and the crucial split between filtering (yes/no, cacheable) and querying (scored).

• BM25 relevance — the actual math behind “why did this document rank first,” so ranking stops being magic.

• Aggregations — using the same index to answer analytical questions, not just search ones.

• Distributed sharding — how one index is split across machines so it can hold and search far more than one node could.

• Design decisions — the judgment of when to reach for Elasticsearch at all, and when your database already has you covered.

Each of those makes sense only in light of the core idea. Analysis matters because search is term lookups, so how you build the terms is everything. Sharding matters because the index can outgrow one machine. The database-alongside architecture matters because the inverted index is a search structure, not a transactional one. Learn the mental model first, and the rest stops being intimidating.

If you can explain why an inverted-index lookup beats a LIKE scan, and why the source of truth still belongs in Postgres, you already understand what Elasticsearch is for.

Hình dung kiến trúc ba tầng thế này. Trên cùng là L1, cache local nằm trong RAM của từng instance, đọc cực nhanh vì không tốn một byte network nào. Dưới nó là L2, con Redis dùng chung cho cả cụm. Dưới cùng là database, nguồn sự thật. Giả sử mình chạy 20 instance của service, thì có nghĩa là có 20 cái L1 riêng biệt, mỗi cái nằm trong một process, và quan trọng là chúng không biết nhau tồn tại.

Luồng đọc thì đẹp và trực giác. Request tới, ngó L1 trước, có thì trả luôn. Không có thì hỏi xuống L2 Redis, có thì nạp ngược lên L1 rồi trả về. L2 cũng không có thì mới xuống database, lấy ra, nạp lên L2, nạp lên L1, rồi trả về. Đi từ nhanh nhất xuống chậm nhất, và trên đường về thì rải dữ liệu ngược lên các tầng. Cái này không có gì để bàn nhiều.

Chỗ bắt đầu đau là luồng ghi. Hồi đầu mình từng nghĩ một hướng nghe rất mượt: cứ đọc ghi hết vào L1 cho nhanh, rồi để một background job cuối vòng đời request đẩy ngược xuống Redis và database. Nghe thì hay, nhưng đây là một cái bẫy, và nó có tên đàng hoàng là write-behind, ghi vào cache trước rồi mới flush xuống store sau. Vấn đề là mình đang đặt cái write-behind đó lên L1 local, tức là lên RAM của một process mong manh. Process đó chết giữa chừng vì deploy hay OOM là dữ liệu chưa flush bay luôn, database không bao giờ thấy. Tệ hơn, hai mươi cái L1 cùng ghi thì mình có hai mươi phiên bản sự thật mâu thuẫn nhau mà chẳng cái nào là chân lý. Cho nên bài học xương máu ở đây là: L1 và L2 là cache, không phải là store. Nguồn sự thật luôn là database. Cache có thể mất bất cứ lúc nào mà hệ thống vẫn phải đúng.

Vậy luồng ghi đúng là gì. Vẫn giữ nguyên hai nguyên tắc từ bài trước: ghi database trước vì nó là nguồn sự thật, và với cache thì xóa chứ không update. Chỉ khác một điều, giờ cái động tác xóa cache phải lan ra hai tầng. Ghi database xong, xóa key ở L2 Redis, rồi tìm cách xóa key đó ở cả 20 cái L1 đang nằm rải rác. Và chính cái vế cuối cùng đó, xóa 20 cái L1, mới là phần khó nhất và thú vị nhất của cả câu chuyện.

Vấn đề này có tên chính thức là local cache coherence, làm sao giữ cho 20 bản copy trong 20 process cùng nhìn thấy một giá trị. Có mấy cách, mình xếp từ nhẹ tới nặng. Cách nhẹ nhất, và cũng là cách mình nghĩ nhiều người bỏ qua một cách đáng tiếc, là chỉ cần cho L1 một TTL thật ngắn, kiểu năm tới ba mươi giây, rồi thôi. Không invalidation, không pub/sub, không gì cả. Chấp nhận rằng dữ liệu ở L1 có thể cũ tối đa vài giây. Với những thứ ít đổi hoặc chấp nhận sai số nhỏ, đây thường là câu trả lời đủ tốt và rẻ nhất. Mình học được rằng một trong những dấu hiệu của người làm hệ thống chín là biết chọn giải pháp đủ dùng thay vì nhảy ngay vào cái phức tạp nhất để trông cho ngầu.

Cách phổ biến hơn khi cần dữ liệu tươi nhanh là pub/sub invalidation. Khi có ghi, cái instance xử lý sẽ publish một message kiểu key X vừa đổi lên một kênh Redis, cả 20 instance đều subscribe kênh đó, nhận được thì tự xóa key X trong L1 của mình. Đây là cách chuẩn mà nhiều hệ near-cache dùng. Nhưng phải hiểu rõ điểm yếu chí mạng của nó: Redis pub/sub là fire-and-forget, gửi một lần rồi thôi, không hề lưu lại message. Cái instance nào đúng lúc đó đang mất kết nối, đang bận GC, hay vừa restart chưa kịp subscribe, thì nó miss luôn cái event xóa, và L1 của nó sẽ ôm giá trị cũ mãi mãi. Đây chính là nỗi lo mất event mà ai làm qua đều thấm.

Cho nên có một nguyên tắc mình muốn nhấn mạnh: pub/sub không bao giờ được đi một mình. Nó luôn phải đi kèm TTL trên L1 làm lưới an toàn. Pub/sub lo cho chín mươi chín phần trăm trường hợp, xóa gần như tức thì trong dưới một giây. Còn TTL lo cho cái một phần trăm sự kiện bị lọt, đảm bảo dù có miss thì cache cũng tự hết hạn sau vài giây chứ không sai vĩnh viễn. Nếu bạn để ý, đây lặp lại đúng cái bài học từ buổi caching đầu tiên: mọi cơ chế invalidation dựa trên event đều cần TTL làm backstop, bởi event thì luôn có thể mất.

Còn nếu bài toán khắt khe tới mức không được phép miss invalidation, thì mình leo lên bậc tin cậy cao hơn: thay pub/sub bằng một message queue hay Redis Streams có lưu trữ, để instance nào restart cũng đọc lại được event đã lỡ, tức là chuyển từ gửi nhiều nhất một lần sang gửi ít nhất một lần. Hoặc dùng tính năng client-side caching của Redis đời mới, nơi chính Redis server theo dõi instance nào đang cache key nào và chủ động đẩy tín hiệu vô hiệu hóa về đúng client đó. Đổi lại thì cái nào cũng phức tạp hơn, và đó luôn là cái giá phải cân.

Nhưng câu chuyện chưa dừng ở việc gửi event cho đáng tin. Ngay cả khi thứ tự đúng và event không mất, vẫn còn một khe hở tinh vi mà mình rất thích. Tưởng tượng một request đọc bị miss cả L1 lẫn L2, nó xuống database đọc, và đúng khoảnh khắc đó nó đọc trúng giá trị cũ vì cái lệnh ghi kia chưa commit xong. Ngay sau đó lệnh ghi commit, xóa L2, bắn event xóa L1. Rồi cái request đọc lúc nãy mới lững thững quay lại, nạp cái giá trị cũ mà nó cầm trên tay vào L2 và L1, tức là nạp sau khi mọi thứ đã bị xóa. Kết quả là cache lại stale, và lần này publish có tin cậy tới đâu cũng vô dụng, vì lỗi không phải mất event, mà là ghi đè sau khi xóa.

Để vá cái khe này, thứ tự đúng là commit database trước đã, xong mới xóa cache và phát event, để không ai bị báo đi đọc lại khi nguồn sự thật còn chưa mới. Nhưng riêng cái race đọc đồng thời ở trên thì cần thêm hai lớp nữa, và cả hai đều đã xuất hiện ở bài trước. Một là delayed double delete, tức là xóa xong chờ một nhịp ngắn rồi xóa lần thứ hai, để dọn đúng cái giá trị cũ mà request đọc kia có thể đã kịp nạp vào. Hai là TTL trên cả L1 lẫn L2 làm tấm lưới cuối cùng, để dù mọi thứ ở trên đều lọt thì cache cũng chỉ sai trong một khoảng bị chặn rồi tự sửa.

Về chuyện phát event cho đáng tin, mình có một khoảnh khắc khá vui khi nhận ra: việc phải ghi vào database rồi phát đi một tín hiệu mà không được mất, chính xác là cái Dual Write Problem và lời giải outbox mà mình từng gặp bên message queue. Cùng một bài toán. Nên có thể dùng outbox để đảm bảo event luôn được gửi. Có điều với riêng bài toán vô hiệu hóa cache thì outbox kiểu polling hơi chậm, vì phải chờ worker quét bảng, làm L1 stale lâu hơn một chút. Nếu muốn vừa tin cậy vừa nhanh thì hướng đẹp hơn là CDC, đọc thẳng binlog của database bằng thứ như Debezium, commit xong là có tín hiệu gần như tức thì mà vẫn không mất. Nghĩa là mình lại quay về đúng bộ công cụ đã bàn ở buổi cache-DB consistency, chỉ khác ngữ cảnh.

Và đây là cái insight mà mình thấy đáng giá nhất của cả buổi. Cái câu hỏi làm sao để 20 bản copy trong 20 process cùng thấy một giá trị, nó không mới. Nó chính là bài toán cache coherence của CPU, nơi mỗi nhân có L1 L2 riêng và phải chạy giao thức để đồng bộ. Nó cũng chính là bài toán replication trong hệ phân tán, nhiều bản sao, có độ trễ lan truyền, có thể mất tin. Và một lần nữa nó lại là Dual Write Problem đội một cái mũ khác: mình đang ghi vào nhiều nơi mà không có một transaction chung nào ôm hết. Khi thấy cùng một bài toán hiện ra dưới ba bốn lớp áo khác nhau, từ con chip cho tới cụm server, mình mới thấm rằng học architecture không phải là học thuộc nhiều giải pháp, mà là nhận ra ít nguyên lý nhưng chúng lặp lại ở khắp mọi nơi.

Chốt lại, điều mình mang theo sau cả chuỗi caching là: không có cách nào làm cho cache nhất quán tuyệt đối với database. Mọi thiết kế tử tế đều chỉ là xếp tầng phòng thủ, invalidation nhanh lo phần lớn, double delete lo cái race, TTL lo phần còn sót lại. Mình không đi tìm giải pháp đúng, mình đi tìm một mức sai lệch đủ nhỏ cho đúng nghiệp vụ này. Mô tả sản phẩm thì cũ vài phút cũng chẳng sao. Giá thì chỉ nên cũ vài giây. Còn tồn kho lúc khách bấm chốt đơn thì mức sai lệch cho phép phải bằng không, nên tuyệt đối không được quyết định dựa trên cache. Biết gắn cái mức sai lệch chấp nhận được đó vào từng loại dữ liệu, theo mình, mới là thứ phân biệt một người thiết kế hệ thống với một người chỉ biết xài Redis.

Mình cũng mới hiểu tới đây thôi, ae nào làm sâu hơn phần near-cache hay client-side caching thì bổ sung giúp, hay muốn mình đào tiếp phần nào cứ nói. Bài tới chắc mình rẽ sang Kafka, vì outbox với CDC nhắc hoài mà chưa mổ tới nơi.

Cho đến hôm mình gặp bài toán này trong một buổi phỏng vấn. Nó bắt đầu bằng một cốc cafe, và kết thúc bằng việc mình nhận ra: thêm index đôi khi không phải là câu trả lời — mà là cách nhanh nhất để giết chết cả hệ thống.

Mình kể lại nguyên văn nhé.

Có một bảng tên events trên PostgreSQL 15. Nó vừa vượt mốc 200 triệu dòng.

Hệ thống ingestion đang chạy ở mức 8.000 writes/giây, đổ vào từ một Kafka consumer. Trước đây P99 write latency là 12ms — mượt. Giờ nó nhảy lên 140ms và vẫn đang tăng (chữ “vẫn đang tăng” này quan trọng lắm, để lát nữa mình quay lại).

Rồi đội làm dashboard thống kê kéo tới. Query của họ lọc theo (tenant_id, event_type, created_at), và mỗi request phải quét 40 triệu dòng. Họ mua cho mình một cốc cafe, cười hiền, bảo: “Cho bọn tớ một cái index thôi mà.”

Nghe thì dễ. Nhưng mình mở pg_stat_user_indexes ra xem thì hơi lạnh sống lưng: bảng này đã có sẵn 4 index rồi. Mỗi lần ghi một dòng mới, cả 4 cái index đó đều phải cập nhật. Người phỏng vấn nói thẳng một câu làm mình nhớ mãi:

“Nếu cậu thêm index thứ 5, ingestion lag sẽ biến thành ingestion failure.”

Tức là: cái write path vốn đã hấp hối ở 140ms, thêm một index nữa là nó gãy hẳn. Dashboard nhanh lên nhưng dữ liệu ngừng chảy vào. Được cái này mất cái kia.

Nhưng có một chi tiết mà lúc đầu mình lướt qua, sau mới thấy nó là chìa khóa: 92% query của dashboard chỉ đụng vào signup event của một tenant, trong 7 ngày gần nhất. Một mẩu tí xíu của cả cái bảng khổng lồ 200 triệu dòng.

Rồi người phỏng vấn đưa ra 4 phương án.

A) Thêm một composite B-tree index trên (tenant_id, event_type, created_at). Sách giáo khoa. Bao trọn query. Xong.

B) Thêm một covering index với INCLUDE (user_id, payload) để query không bao giờ phải chạm vào heap nữa — index-only scan, đọc bay.

C) Ngừng đụng vào index trên bảng chính. Tạo một read replica, đẩy toàn bộ query dashboard sang đó. Giữ luồng write luôn gọn nhẹ.

D) Thêm một partial index, vẫn trên các cột đó, nhưng kèm điều kiện:

WHERE event_type = 'signup'
  AND created_at > now() - interval '7 days'

Chỉ đánh index đúng phần dữ liệu “nóng”.

Cả bốn đều là mô hình thật, dùng trong production thật. Ba trong số đó sẽ làm dashboard nhanh lên. Nhưng chỉ một cái làm được điều đó mà không đạp vỡ write throughput.

Mình đoán được anh em đọc tới đây đã biết đáp án là D. Nhưng cái hay của buổi phỏng vấn không nằm ở chữ “D” — nó nằm ở câu hỏi “tại sao ba cái kia sai?” và “D thoát bằng cơ chế gì?”. Mình đi từng cái.

Vì sao A và B giết write path

Muốn hiểu tại sao thêm index lại nguy hiểm đến thế, mình phải hiểu một cái INSERT thực ra tốn kém cỡ nào.

Trước đây mình tưởng insert một dòng là ghi một chỗ. Sai. Trong Postgres, một dòng insert vào bảng có N index thực ra là:

1 heap tuple + N index entry + WAL cho tất cả + (có thể) page split + (có thể) full-page write.

Mỗi index là một cây B-tree độc lập, riêng biệt. Nó không chia sẻ gì với các index khác. Thêm index thứ 5 nghĩa là thêm nguyên một cái cây phải bảo trì đồng bộ, trong cùng một transaction, mỗi lần ghi.

Và cái đắt nhất không phải là “chèn vào lá cây”. Cái đắt nhất là page split.

Hình dung thế này. Mỗi trang (page) trong B-tree chỉ chứa được 8KB, và các key phải nằm sắp xếp thứ tự trong đó. Khi bạn chèn vào một trang đã đầy, Postgres phải:

1. Xin một trang mới,

2. Chia đôi đống key sang trang mới (copy dữ liệu),

3. Sửa con trỏ ở trang cha để trỏ tới trang mới,

4. Và nếu trang cha cũng đầy — cha lại split, lan lên trên, có khi tới tận gốc cây.

Một cú split là ghi lại 2-3 trang thay vì sửa nhẹ 1 trang. Và tất cả đều phải ghi vào WAL (write-ahead log — Postgres ghi log trước, ghi data sau, để lỡ crash còn khôi phục được).

Đây là chỗ mình vỡ ra: với index trên cột ngẫu nhiên như tenant_id hay event_type, entry mới rơi vào giữa cây, chỗ nào cũng có thể split. Còn WAL thì là một dòng ghi tuần tự chung cho cả instance — nó là điểm nghẽn cổ chai, mọi commit đều phải xếp hàng qua đó. Thêm index = thêm WAL = fsync lâu hơn = commit lâu hơn = P99 tăng cho toàn bộ write, không riêng gì query mới.

Chưa hết, còn một cú nhân đôi ngầm nữa tên là full-page write: sau mỗi checkpoint, lần đầu một trang bị chạm, Postgres ghi nguyên cả trang 8KB vào WAL (chống lỗi torn-page). Index thứ 5 chạm thêm nhiều trang mới → WAL phình gấp mấy lần dữ liệu thật.

Giờ quay lại chữ “vẫn đang tăng” ở đề bài. Đó không phải chi tiết trang trí. Khi một hệ thống chạy gần trần I/O (utilization tiến tới 100%), latency không tăng tuyến tính nữa — nó dựng đứng theo lý thuyết hàng đợi. Nghĩa là 4 index đang đẩy hệ tới sát mép vực. Trực giác “đang có 4, thêm 1 nữa chỉ +25% thôi mà” là sai chết người — vì bạn đang cộng thêm tải vào một hệ đã gần bão hòa. Đó chính xác là lý do phương án A sập.

Còn B thì sao? Nó còn tệ hơn. INCLUDE (payload) — mà payload thường là JSON to đùng — nhét cả cục đó vào index. Index phình khủng khiếp, write amplification tăng vọt, WAL càng nặng. B tối ưu read bằng cách hy sinh write nặng nhất trong cả bốn. Sai hoàn toàn hướng, vì vấn đề của mình đang là write.

(Còn một con dao ngầm nữa mà mình chỉ nói ngắn: nếu bảng có UPDATE, thì mỗi index bạn thêm vào sẽ thu hẹp cơ hội HOT update — cái tối ưu cho phép Postgres cập nhật tuple ngay trong heap page mà không đụng index nào. Chỉ cần cột bị update lọt vào một index thôi là HOT bị hủy, phải cập nhật tất cả index. Nhưng đề này thiên về insert, nên mình để dành chuyện đó cho một bài khác.)

Vì sao C — read replica — nghe hay mà chưa trúng

Cái này lừa được kha khá người, kể cả mình lúc đầu. Read replica nghe rất “kiến trúc sư”: tách read khỏi write, giữ primary gọn nhẹ. Và về lâu dài thì đúng, bạn sẽ cần nó thật.

Nhưng nó không trị được bệnh gốc. Replica là bản sao y hệt của primary — nó thừa hưởng nguyên xi cấu trúc index. Query trên replica vẫn phải quét 40 triệu dòng, vì nó vẫn thiếu đúng cái index phù hợp. Chậm vẫn hoàn chậm.

“Thì thêm index trên replica!” — ừ, nhưng index trên replica được replay từ WAL của primary. Muốn có index trên replica thì phải tạo nó trên primary trước. Và thế là ta quay lại đúng cái vòng luẩn quẩn ban đầu: đụng vào write path.

C giải quyết bài toán scale read (đúng, nhưng chưa phải bây giờ). Nó không giải quyết bài toán thiếu một index đủ rẻ. Nó tách write và read ra hai máy, chứ không làm query tự nhiên nhanh lên.

Vì sao D thắng: đừng đánh index cả cái bảng khi giá trị nằm ở một góc nhỏ

Giờ tới cái đẹp. Nhớ lại: 92% event không phải signup.

Partial index chỉ đánh index đúng phần dữ liệu thỏa điều kiện WHERE:

CREATE INDEX CONCURRENTLY idx_events_signup_hot
ON events (tenant_id, created_at)
WHERE event_type = 'signup'
  AND created_at > '2026-07-05 00:00:00';

Chuyện gì xảy ra khi một dòng mới insert vào?

• Nếu nó là event_type = 'click' (92% trường hợp) → Postgres kiểm tra điều kiện WHERE, thấy không khớp, và hoàn toàn không đụng vào cái cây này. Không đi cây, không split, không ghi WAL cho index, không phá HOT. Chi phí bằng không.

• Nếu nó là signup (8%) → mới tạo entry. Mà cây thì bé (chỉ chứa signup của mấy ngày gần đây), nông, nằm gọn trong cache → split hiếm, full-page write hiếm.

So sánh cho rõ: phương án A bắt 100% số write trả phí cho cây thứ 5. Partial index chỉ bắt 8% trả phí, và trả rẻ hơn nhiều. Đây là toàn bộ trò ảo thuật, và nó gói gọn trong một câu mà mình muốn khắc lên tường:

Write amplification tỉ lệ với phần dữ liệu bạn đánh index — không phải với việc bạn có index hay không.

Index nhỏ còn kéo theo read nhanh: cây bé thì nằm trong RAM, cache hit cao, dashboard bay. Vừa cứu write, vừa cứu read. Đổi lại một cốc cafe. Quá hời.

Nhưng D có một cái bẫy (và đây mới là chỗ phỏng vấn thật sự bắt đầu)

Anh em có để ý mình lén đổi cái điều kiện không? Đề bài viết created_at > now() - interval '7 days', nhưng câu lệnh mình gõ lại là một mốc cứng: '2026-07-05'. Không phải mình gõ nhầm.

Đây là chỗ người phỏng vấn nhếch mép hỏi: “Cậu viết now() vào predicate à? Chắc chưa?”

Hóa ra có hai vấn đề.

Thứ nhất, Postgres không cho. now() là hàm STABLE, không phải IMMUTABLE. Mà predicate của partial index bắt buộc phải immutable. Gõ now() vào là nó ném lỗi thẳng mặt:

ERROR: functions in index predicate must be marked IMMUTABLE

Thứ hai, kể cả gõ được thì cũng sai về mặt ngữ nghĩa. Predicate của partial index được đánh giá đúng một lần, tại thời điểm CREATE INDEX, rồi đóng băng vĩnh viễn vào catalog. Nó không phải biểu thức “sống” được tính lại mỗi query.

Nghĩa là: hôm nay bạn tạo index với “7 ngày gần nhất” = từ 28/06. Mười ngày sau, thế giới đã trôi tới 15/07, nhưng cái index vẫn đóng băng ở mốc 28/06. Query của dashboard vẫn hỏi “7 ngày gần nhất” (giờ là từ 08/07) — và planner nhìn vào index, thấy nó không chắc chứa đủ dữ liệu cho khoảng đó, nên bỏ không dùng index nữa, quay về quét tuần tự 40 triệu dòng. Index vẫn nằm đó, vẫn ăn chi phí write, nhưng vô dụng. Tệ nhất của cả hai thế giới.

Nên partial index thời gian là một thứ “stateful” — nó không tự trượt. Bạn buộc phải hardcode mốc cứng, rồi định kỳ xây lại với mốc mới. Và câu hỏi tiếp theo của người phỏng vấn là: “Xây lại thế nào mà không downtime? Cậu đang có 8.000 writes/giây đấy.”

Xây lại index mà không chặn write: CREATE INDEX CONCURRENTLY

Nếu bạn gõ CREATE INDEX bình thường, Postgres sẽ khóa bảng ở chế độ SHARE — chặn toàn bộ write trong suốt thời gian build. Với bảng lớn, đó là vài phút. Với 8.000 writes/giây, đó là thảm họa.

Cứu tinh là CREATE INDEX CONCURRENTLY (viết tắt CIC). Nó đánh đổi: build lâu hơn, nhưng không chặn write. Cách nó làm phép là quét bảng hai lần và biết chờ đúng lúc:

• Lần 1 — đăng ký: ghi index vào catalog nhưng đánh dấu “chưa sẵn sàng, chưa hợp lệ”. Rồi đợi mọi transaction đang chạy dở kết thúc (vì chúng chưa biết đến index mới).

• Lần 2 — build: chụp một snapshot, quét cả bảng, dựng cây. Từ đây mọi write mới bắt đầu cập nhật index, nhưng query thì chưa dùng.

• Lần 3 — validate: quét bảng lần nữa để nhặt những dòng được ghi trong lúc đang build (snapshot cũ chưa thấy), rồi mới đánh dấu index “hợp lệ” cho planner dùng.

Cái giá của “không downtime” là quét bảng hai lần, tốn gấp đôi I/O. Nhưng write không bao giờ bị chặn quá vài mili-giây.

Có ba cái bẫy của CIC mà mình học được (một cách đau đớn):

1. Không chạy được trong transaction block. Nhiều framework migration bọc mọi thứ trong BEGIN...COMMIT — phải tắt cái đó đi.

2. Nếu CIC thất bại giữa chừng, nó để lại một index “invalid” và không tự dọn. Cái xác đó vẫn ăn chi phí write mà không phục vụ query nào. Bạn phải tự DROP INDEX CONCURRENTLY nó đi. (Nên script xây lại luôn phải dọn xác đầu tiên, và phải chạy lại được nhiều lần — idempotent.)

3. Một transaction sống lâu sẽ treo CIC vô hạn, vì CIC phải đợi transaction cũ kết thúc. Một ông BEGIN rồi đi ăn trưa, một cursor để mở, một pg_dump chạy lâu — đủ để CIC đứng hình. Trước khi xây lại, luôn soi pg_stat_activity xem có ông nào ngồi lâu không.

Và pattern xây-lại-không-downtime hoàn chỉnh, mình gọi là build-then-swap:

-- 1. Dọn xác invalid index từ lần trước (idempotent)
DROP INDEX CONCURRENTLY IF EXISTS idx_events_signup_hot_new;

-- 2. Build index mới với mốc trượt tới, KHÔNG chặn write
CREATE INDEX CONCURRENTLY idx_events_signup_hot_new
ON events (tenant_id, created_at)
WHERE event_type = 'signup'
  AND created_at > '2026-07-05 00:00:00';

-- 3. Đổi tên — thao tác catalog, nhanh như chớp
BEGIN;
  ALTER INDEX idx_events_signup_hot     RENAME TO idx_events_signup_hot_old;
  ALTER INDEX idx_events_signup_hot_new RENAME TO idx_events_signup_hot;
COMMIT;

-- 4. Dọn index cũ
DROP INDEX CONCURRENTLY idx_events_signup_hot_old;

Suốt bước 2, index cũ vẫn phục vụ query bình thường — dashboard không hụt một giây. Đóng gói cái này vào một job pg_cron chạy 3 giờ sáng mỗi ngày (nhớ để một khoảng đệm — index phủ 10 ngày cho query 7 ngày, để không bao giờ chạm mép), và bạn có một “cửa sổ nóng” tự trượt theo lịch.

(Nếu chỉ muốn dọn bloat mà không đổi predicate thì có REINDEX INDEX CONCURRENTLY — nó tự swap và tự dọn, an toàn hơn. Nhưng đổi predicate — tức đổi mốc thời gian — thì bắt buộc phải build cái mới, REINDEX không giúp được.)

Tới đây thì mình đã có một lời giải chạy được trong production. Nhưng ngồi trên ghế phỏng vấn, mình nghe câu hỏi mà mọi kiến trúc sư đều biết sẽ tới: “Ừ, hay đấy. Thế 6 tháng nữa, bảng lên 1 tỉ dòng, cậu vẫn đi xây lại index mỗi đêm à?”

Cấp độ cuối: đừng vá index nữa, hãy chia luôn cái bảng

Suốt nãy giờ, mình vật lộn với một sự thật ngầm: bảng là một khối 200 triệu dòng liền mạch. Mọi index đều phải sống trên cả khối đó. Partial index chỉ là mẹo “giả vờ” chia nhỏ ở tầng index — còn cái heap (dữ liệu thật) vẫn nguyên một cục.

Partitioning giải quyết tận gốc: chia luôn cái heap.

Bảng events trở thành một bảng “cha” — chỉ là định nghĩa, không chứa dữ liệu. Dữ liệu thật nằm trong nhiều bảng con, mỗi con phủ một khoảng thời gian:

events (cha, rỗng)
├── events_2026_06_w1   (01–07/06)   ← nguội
├── ...
├── events_2026_07_w1   (01–07/07)   ← NÓNG, đang ghi
└── events_2026_07_w2   (tương lai)

CREATE TABLE events (
    id          bigint GENERATED ALWAYS AS IDENTITY,
    tenant_id   bigint NOT NULL,
    event_type  text   NOT NULL,
    payload     jsonb,
    created_at  timestamptz NOT NULL
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2026_07_w1
    PARTITION OF events
    FOR VALUES FROM ('2026-07-01') TO ('2026-07-08');

Khi ứng dụng INSERT INTO events, Postgres tự routing dòng đó xuống đúng partition dựa trên created_at. Ứng dụng không cần biết partition tồn tại.

Cái này thay đổi mọi thứ, theo ba hướng.

1. Index trở thành “local” — mỗi partition một cây bé xíu. Khi bạn tạo index trên bảng cha, Postgres tạo một cây riêng trên mỗi partition. Insert của tuần này chỉ cập nhật index của events_2026_07_w1 — một cây chỉ vài triệu dòng, chứ không phải cây 200 triệu. Nhớ lại bài học page split ở trên: cây bé → nông hơn, split hiếm hơn, nằm gọn trong RAM. Toàn bộ đám quái vật write amplification bị thu nhỏ lại. Và index của partition cũ thì nguội hẳn — không ai ghi vào tháng trước nữa, nên chúng không split, không tạo WAL, không tranh cache. Write path chỉ còn nóng ở đúng một partition. Đây là thứ mà cả A, B, C, D đều không làm được: cô lập chi phí write về mặt vật lý theo thời gian.

2. Partition pruning cứu read — và chữa luôn cái bẫy now(). Khi dashboard query WHERE created_at > now() - interval '7 days', planner loại thẳng mọi partition không thể chứa dữ liệu đó, không thèm mở. Và quan trọng: pruning này chạy được ở run-time (Postgres 11+) — nghĩa là now() được tính lúc chạy, không cần đóng băng như partial index. Data tự “già đi” khi lịch trôi, partition cũ tự nhiên rơi khỏi tầm ngắm. Cái bẫy now() bắt mình phải rebuild mỗi đêm ở phương án D — ở đây biến mất.

3. Xóa data cũ từ “chiến dịch hàng đêm đau khổ” thành một dòng lệnh. Với bảng thường, DELETE FROM events WHERE created_at < ... mấy chục triệu dòng là đẻ ra mấy chục triệu dead tuple, VACUUM chạy vã mồ hôi, bloat, lock, bão I/O. Với partition, “xóa data 90 ngày trước” chỉ là:

ALTER TABLE events DETACH PARTITION events_2026_04_w1 CONCURRENTLY;
DROP TABLE events_2026_04_w1;

DROP TABLE một partition gần như tức thời — xóa file, không dead tuple, không cần VACUUM. Người ta gọi là partition rotation.

Partitioning cũng không miễn phí — mấy cái phải thuộc lòng

Mình không muốn vẽ ra một bức tranh màu hồng. Partitioning trả bằng độ phức tạp, và đây là những chỗ mình từng vấp (hoặc thấy người khác vấp):

• Partition key phải nằm trong mọi UNIQUE / PRIMARY KEY. Postgres không có unique index toàn cục xuyên partition. Muốn có primary key thì created_at bắt buộc phải là một phần của nó: PRIMARY KEY (id, created_at), không thể chỉ (id). Nếu code cũ dựa vào id unique toàn cục hay có foreign key trỏ tới, đây là chỗ đau đầu nhất khi migrate.

• Query không kèm partition key thì không prune được. Nếu dashboard đôi khi query WHERE tenant_id = 42 mà quên điều kiện thời gian → Postgres quét mọi partition. May là 92% query của mình đều có “7 ngày gần nhất” — khớp hoàn hảo.

• Quá nhiều partition thì planner phình. Vài trăm cái thì ổn, vài nghìn thì planning time và bộ nhớ tăng. Đừng partition theo giờ nếu retention là hàng năm.

• Phải tạo trước partition tương lai. Đến 0h ngày sang tuần mới mà chưa có partition → insert lỗi hàng loạt → ingestion sập. Kinh điển. Đừng tự viết cron tay — dùng pg_partman, nó lo pre-create và retention cho bạn.

Và cái khó nhất, thứ mà mình nghĩ mới thực sự phân loại người trong phỏng vấn: làm sao migrate 200 triệu dòng đang chạy 8.000 writes/giây sang partitioned mà không downtime? Bạn không thể ALTER TABLE ... PARTITION BY tại chỗ — Postgres không cho biến bảng thường thành partitioned. Có ba đường:

• Big-bang (tạo bảng mới, copy hết, đổi tên): loại — copy 200 triệu dòng mất hàng giờ trong khi write vẫn đổ vào.

• Dual-write + backfill: cho ứng dụng ghi song song vào cả bảng cũ và bảng mới, rồi backfill dữ liệu lịch sử theo từng lô nhỏ (ngủ giữa các lô để không giết I/O), verify khớp, rồi mới swap. Chắc cú, rollback dễ.

• ATTACH bảng cũ làm một partition: đây là mẹo mình thích nhất. Tạo bảng cha rỗng, đổi tên bảng 200 triệu dòng thành events_legacy, thêm một CHECK constraint hợp lệ để Postgres biết khoảng của nó (để khỏi phải quét cả bảng lúc attach), rồi ATTACH nó vào làm partition quá khứ. Không copy một byte nào. Data mới rơi vào partition mới, cục legacy nằm im, nguội dần, rồi tới hạn thì drop. Thực dụng nhất cho tình huống này.

Vậy rốt cuộc chọn gì?

Đây là chỗ mình nghĩ nhiều người trả lời phỏng vấn bị hụt: họ tìm một đáp án đúng. Nhưng bài này không có một đáp án — nó có một trình tự trưởng thành:

• Hôm nay, đổi cốc cafe: dùng D — partial index. Vá ngay, ít rủi ro, không đổi schema, dashboard nhanh trong chiều nay. Nhớ hardcode mốc thời gian và dựng job rebuild-concurrently.

• Khi bảng còn phình và retention thành vấn đề: chuyển sang partitioning theo thời gian. Index local nên write rẻ, pruning run-time nên now() chạy tự nhiên, retention thành DROP một partition.

• Khi read scale vượt một node: lúc đó C — read replica mới thực sự vào đúng vai, và nó chạy trên một bảng đã partition nên còn nhanh hơn nữa.

Ba tầng này bổ sung nhau, không loại trừ. Một bảng partitioned vẫn có thể có partial index local trên partition nóng, và vẫn replicate sang replica. Cái sai duy nhất là nhảy thẳng vào A hay B — thêm một index full-table vào một write path đang hấp hối.

Nếu phải gói cả bài vào một câu để mang đi phỏng vấn, mình sẽ nói thế này:

Đừng đánh index cả cái bảng khi 92% giá trị nằm trong một góc nhỏ. Write amplification tỉ lệ với phần dữ liệu bạn index, không phải với việc bạn có index hay không. Partial index cắt chi phí đó xuống còn phần nóng; partitioning cô lập luôn phần nóng về mặt vật lý và cho now() chạy tự nhiên không cần đóng băng; read replica là để scale read sau cùng, không phải để chữa một index thiếu.

Thú thật là mình cũng mới hiểu tới mức này thôi. Còn kha khá thứ mình cố tình để dành cho bài sau — chuyện HOT update bị index phá vỡ, chuyện tính fillfactor bằng số cụ thể để giảm split, chuyện đọc EXPLAIN (ANALYZE, BUFFERS) để chứng minh pruning có thật sự xảy ra hay không.

Nếu anh em từng gặp bài toán này ngoài đời — hoặc có một góc nhìn khác về chuyện chọn D so với partitioning — thì kể mình nghe với. Mình vẫn đang học, và mấy bài học kiểu này hay nhất là khi ngồi cãi nhau qua lại. ☕

Mà chốt sổ kiểu gì cũng phải bắt đầu bằng một cú tát nhẹ vào mặt mình của mấy tháng trước. Hồi đó mình hỏi câu này một cách rất hồn nhiên, kiểu nó là một bài toán trắc nghiệm có hai đáp án A với B, chọn một cái là xong. Càng học mình càng nhận ra cái câu "Kafka hay RabbitMQ" nó sai ngay từ trong trứng, không phải vì hai đáp án sai, mà vì nó là một câu hỏi "hoặc" trong khi đời thật là một câu hỏi "và". Nhưng từ từ, để mình kể có đầu có đuôi.

Cái lỗi to nhất, lỗi mà mình thấy 9 trên 10 dev mắc kể cả mình, là nhảy thẳng vào chọn công cụ trước khi hỏi xem mình có cần nó không. Câu hỏi đúng nó phải có ba tầng, đi theo thứ tự. Tầng một, mình có thực sự cần async không. Tầng hai, nếu cần async thật thì mình cần một cái queue hay cần một cái log. Tầng ba, mới tới mấy chuyện chi tiết như tải, ordering, replay, fan-out. Đa số người nhảy phắt vào tầng hai, bỏ qua tầng một, và đó là cái lỗi kiến trúc đắt tiền nhất, mình sẽ quay lại chuyện "đừng dùng queue" ở cuối bài vì nó hay lắm.

Giờ giả sử mình đã chắc là cần async rồi, thì tới cái phần phân biệt hai thằng. Mình kể lại nhanh cái mental model ở bài trước vì nó là nền của mọi thứ. RabbitMQ nó là kiểu broker thông minh consumer ngu, message tới tay consumer, xử lý xong ack một phát là nó xóa luôn, y như cuốn sổ to-do làm xong gạch đi. Còn Kafka thì broker ngu consumer thông minh, message ghi vào một cái log chỉ ghi thêm không xóa, nó nằm đó theo retention, consumer tự nhớ mình đọc tới đâu bằng offset, nhiều phe đọc cùng một đống mà không đụng nhau, thích thì tua lại từ đầu. Hai cái triết lý ngược nhau hoàn toàn chứ không phải hai phiên bản của cùng một thứ.

Để mình nói cụ thể RabbitMQ nó tỏa sáng lúc nào, vì cái này quan trọng. Bản chất của nó là message giống như một cái task cần được làm cho xong rồi biến mất. Nên nó hợp nhất với mấy việc kiểu job queue, gửi mail, resize ảnh, xuất file PDF, mỗi message là một việc, làm xong là xong, chẳng ai cần đọc lại làm gì. Nó cũng mạnh kinh khủng ở khoản routing, nó có cái khái niệm exchange với đủ kiểu direct topic fanout, nên nếu nghiệp vụ của bạn kiểu đơn VIP đẩy qua consumer này, đơn thường đẩy qua consumer kia, đơn lỗi quăng vào dead-letter queue, thì cái logic định tuyến đó nằm sẵn trong broker rồi, bạn không phải tự code. Rồi cái khoản ack từng message với redelivery nó cũng làm cực mượt, consumer chết giữa chừng chưa kịp ack hả, message tự quay lại queue cho thằng consumer khác bốc, cần retry có delay, cần dead-letter, cần TTL cho từng message, RabbitMQ lo hết. Và nó hợp với kiểu nhiều worker giành nhau rút từ một queue, ai rảnh thì lấy, muốn nhanh hơn thì đẻ thêm worker. Nhưng nhớ cái điểm yếu cốt tử: message biến mất sau khi ack, không tua lại được, và về cơ bản là một phe ăn cái message đó thôi.

Kafka thì ngược lại hoàn toàn. Message với nó không phải là task, mà là một sự kiện đã xảy ra và là sự thật vĩnh viễn, kiểu OrderPlaced, PaymentCaptured. Và cái siêu năng lực thật sự của Kafka, cái mà mình nghĩ nhiều người dùng Kafka mà còn không xài tới, là fan-out. Tưởng tượng một cái topic orders, mà có năm nhóm consumer khác nhau cùng đọc, một thằng làm analytics, một thằng đánh index search, một thằng chạy fraud, một thằng bắn notification, một thằng đổ vào data warehouse, mỗi thằng giữ offset riêng của nó, chẳng đứa nào đụng đứa nào, chẳng đứa nào làm mất phần của đứa nào. Với RabbitMQ thì để làm được vậy bạn phải nhân bản cái message ra năm cái queue. Rồi cái khoản replay nữa, nó như cỗ máy thời gian, service bug xử lý sai ba ngày event hả, tua offset về cho chạy lại, hay onboard một service mới toanh cần dữ liệu lịch sử hả, cho nó đọc topic từ đầu, RabbitMQ chịu chết khoản này. Cộng thêm throughput thì khủng khiếp, hàng triệu message một giây, và nó đảm bảo thứ tự trong một partition, nên bạn key theo orderId là mọi event của cùng một đơn vào cùng một partition, đúng thứ tự cho đơn đó mà vẫn chạy song song giữa các đơn khác nhau. Đổi lại thì vận hành nó nặng đô hơn, routing phức tạp thì nó không có, mọi logic phải nằm ở consumer.

Mình thích cô đọng cả cái mớ trên thành đúng một câu hỏi để khỏi phải nhớ dài dòng, và mình nghĩ ae nên khắc cái này vô đầu: sau khi xử lý xong, cái message này nó còn cần tồn tại cho ai khác hoặc cho lần sau không. Còn thì Kafka, không thì RabbitMQ. Có một câu hỏi phụ đi kèm cũng hay, là có bao nhiêu phe độc lập cần đọc cùng một dữ liệu này. Một phe thì RabbitMQ vô tư, nhiều phe mỗi phe một nhịp độ thỉnh thoảng cần tua lại thì Kafka.

Giờ tới cái phần mà mình nghĩ là hay nhất của cả bài, cái phần mà ít ai dạy nhưng nó mới là dấu hiệu của một người làm kiến trúc thật chứ không phải người thích nghịch đồ chơi mới: khi nào thì đừng có dùng queue cho mệt. Đừng nhét queue vào khi bạn cần câu trả lời ngay, kiểu user bấm nút phải thấy kết quả liền, check số dư, validate cái form, query cái giá, mấy cái đó nhét queue vào là tự đẻ ra cả đống phức tạp correlation id với callback cho một thứ vốn dĩ chỉ cần một cú HTTP call, async không làm nó nhanh hơn đâu nó chỉ làm nó khó hơn thôi. Đừng dùng khi bạn cần consistency mạnh đọc xong ghi là phải thấy ngay, vì queue nó cho bạn eventual consistency, cái khoảng trễ "đã ghi mà chưa thấy" đó nhiều nghiệp vụ không chịu nổi. Đừng dùng khi tải nhỏ và đều không có spike gì, vì queue sinh ra để san tải với gỡ dính, không có spike để san không có gì để gỡ thì bạn đang trả cái giá vận hành nuôi thêm một hệ phân tán để đổi lấy một lợi ích bằng không. Đừng dùng khi hai service đằng nào cũng phải sống cùng nhau, kiểu A gọi B mà B chết thì A cũng vô nghĩa luôn, thì cái sự gỡ dính nó là ảo, cứ gọi thẳng cho đơn giản.

Và đây là hai cái mình tâm đắc nhất trong cái mục "đừng dùng queue". Thứ nhất, rất nhiều khi một cái bảng trong database là quá đủ. Volume vừa phải thôi thì một cái bảng jobs với câu SELECT FOR UPDATE SKIP LOCKED nó làm queue ngon lành, mà lại transactional chung với business data luôn, dễ debug, không thêm một cục hạ tầng nào. Đừng có kéo nguyên con Kafka về chỉ để xử lý một nghìn job một ngày, nó như lấy dao mổ trâu giết gà vậy. Thứ hai, và cái này nối thẳng vào chủ đề bài trước nên mình mê: nhiều khi vấn đề thật của bạn không phải là messaging mà là dual-write. Rất nhiều người nhét Kafka vào để "ghi DB xong rồi publish event", rồi dính đúng cái khe nứt mà mình kể bài trước, ghi DB xong, publish event thì crash, thế là DB có mà event mất, hệ thống lệch nhau. Queue không cứu được cái này đâu. Thứ cứu được nó là Transactional Outbox, tức là bạn ghi business data với cái event vào chung một transaction của database, event nằm trong một cái bảng outbox, rồi một thằng relay đọc cái bảng outbox đó đẩy sang broker. Cái khoảnh khắc bạn nhận ra "à hóa ra mình cần outbox chứ không phải cần đổi broker" là một bước trưởng thành thật sự đó.

Rồi, giờ mới tới phần trả lời cái câu hỏi gốc, cái câu mà mình nợ ae từ bài trước. Order processing thì nên Kafka hay RabbitMQ. Và câu trả lời của một người làm kiến trúc thật nó là thế này: không phải một cái, và cũng không phải vì cái lý do mà mình tưởng hồi đầu. Nhớ không, hồi đầu mình chọn Kafka với lý do message còn lưu nên rollback dễ, mà cái đó sai cả về Kafka lẫn sai về rollback luôn. Giờ với cái đầu sáng hơn một tí thì mình thấy nó phải tách làm hai phần.

Cái phần lõi của saga, đặt hàng rồi giữ kho rồi trừ tiền rồi giao vận, cái đám đó là mệnh lệnh chứ không phải sự kiện, và nó nên đi bằng RabbitMQ, hoặc đúng hơn là đi bằng command thông qua một cái orchestrator bền bỉ kiểu Temporal hay Step Functions. Tại sao lại RabbitMQ. Vì mỗi cái lệnh CapturePayment nó chỉ có nghĩa với đúng một người nhận, làm đúng một việc, làm xong là hết giá trị, chẳng phe thứ hai nào quan tâm, và nó cần cái cơ chế ack với retry với dead-letter tinh vi, đó đúng là sân nhà của RabbitMQ. Còn cái siêu năng lực của Kafka là fan-out với replay thì ở đây vô dụng hoàn toàn, dùng Kafka cho một cái lệnh chỉ tiêu thụ đúng một lần thì như mua nguyên cái xe tải để chở một thùng sữa vậy.

Còn cái phần phát tán ra thế giới thì khác. Khi đơn đã chốt xong xuôi, bạn phát một cái event OrderCompleted lên Kafka, để cho analytics, search index, recommendation, data warehouse, email marketing, đủ thứ phe, mỗi phe tự đọc theo nhịp của nó, tua lại được khi cần. Cái này mới đúng tạng Kafka. Và để cái event đó không bao giờ lệch với database thì lại quay về Outbox chứ đừng có tin vào cái kiểu "publish sau khi commit".

Thấy chưa, kiến trúc thật nó là hybrid, RabbitMQ với orchestrator lo cái phần ra lệnh và điều khiển của saga, Kafka lo cái phần phát tán event ra ngoại vi, outbox để nối database với broker một cách an toàn. Cái câu "Kafka hay RabbitMQ" nó sai vì nó là câu hỏi "hoặc", trong khi sự thật là "và", hai thằng làm hai vai khác nhau trong cùng một hệ thống.

À mà có một cái bẫy tư duy nho nhỏ ở đây mình muốn kể, vì hồi mình tự trả lời câu này mình suýt vấp. Khi giải thích tại sao saga lõi dùng RabbitMQ chứ không Kafka, mình đã định nói "vì saga không cần ordering nên không cần Kafka". Nghe thì xuôi tai mà sai bét. Saga cực kỳ cần đúng thứ tự chứ, giữ kho rồi mới trừ tiền rồi mới giao hàng, đảo lộn là chết liền, thứ tự là chuyện sống còn. Cái đúng phải là, thứ tự ở đây do thằng orchestrator nó đảm bảo bằng cái máy trạng thái của nó, chứ không phải do broker đảm bảo. Kafka nó cho bạn ordering ở tầng hạ tầng, cái đó hữu ích khi bạn cần một dòng event tự nó đã đúng thứ tự cho nhiều phe đọc lại. Nhưng trong saga, cái quyết định bước nào tiếp theo là cái state machine với cái state trong database, chứ không phải vị trí của message trong cái log. Thứ tự nó được sinh ra từ logic, chứ không phải được thừa kế từ broker. Nên Kafka mang cái ordering của nó tới đây là thừa, chứ không phải là "không cần thứ tự". Cái sự phân biệt nhỏ xíu này mà nói trật trong một buổi design review là lòi ra ngay mình chưa nắm chắc đó.

Thôi mình gói lại bằng một bộ luật bỏ túi, ae mang đi phỏng vấn hay đi design review xài được luôn. Cần trả lời ngay, cần consistency mạnh, hay tải nhỏ thì đừng có queue, gọi thẳng hoặc xài một cái bảng database. Task làm xong là xong, routing phức tạp, nhiều worker giành nhau, một phe đọc thì RabbitMQ. Sự kiện là sự thật lâu dài, nhiều phe đọc độc lập, cần tua lại, throughput khủng, thứ tự theo key thì Kafka. Saga nhiều bước cần kiểm soát và recovery thì một cái orchestrator bền bỉ còn hơn tự ôm broker. Phát event sau khi ghi database thì dùng Outbox, đừng dual-write. Và hệ thật thì thường trộn mấy cái trên lại theo từng vai trò chứ hiếm khi thuần một loại.

Ngồi nhìn lại cả cái series này thì hơi buồn cười, mình khởi đầu bằng cái ý định chọn Kafka cho dễ rollback, một câu mà giờ nhìn lại thấy sai từ chân tơ kẽ tóc, sai về Kafka, sai về rollback, sai luôn cả về cách đặt câu hỏi. Mà cuối cùng cái mình mang về không phải là đáp án "chọn thằng nào", mà là khả năng phân biệt được lệnh với sự kiện, queue với log, thứ tự do broker với thứ tự do orchestrator, và quan trọng nhất là biết lúc nào thì đừng đụng vào queue. Mình nghĩ đó mới đúng là khác biệt giữa "biết Kafka là cái gì" với "biết khi nào và tại sao nên dùng nó". Và hình như cái thứ hai mới là thứ người ta trả tiền cho một ông architect ;)) chứ cái thứ nhất thì Google ba giây ra mà.

Hẹn ae bài sau, chắc mình sẽ đào vào cái vụ exactly-once nó là huyền thoại hay có thật, hoặc cái Outbox với Debezium làm tay chân thế nào, tại mình thấy nợ ae cái món outbox này nhắc hoài mà chưa mổ. Ai hóng cái nào thì comment cho mình biết nha.

Nghe thì cứ tưởng Google 5 phút là xong, ai dè đào tới đáy thì mới thấy cái câu trả lời "Kafka hay RabbitMQ" nó chẳng quan trọng bằng đống thứ mình vỡ ra trên đường đi. Mà thật ra cho tới giờ mình vẫn chưa trả lời cái câu gốc đó luôn ;)) để dành bài sau. Bài này mình kể cái hành trình thôi, vì nó mới là phần hay.

Đầu tiên phải nói luôn cái này, vì hồi xưa mình toàn bị ngược: đừng chọn công cụ trước khi hiểu vấn đề. Cái queue nó sinh ra để giải quyết gì? Tưởng tượng cái API đăng ký user của bạn làm tuần tự đồng bộ hết: lưu DB, gửi mail welcome, tạo profile, sync sang CRM, đẩy event analytics. User bấm một phát phải ngồi đợi cả 5 bước chạy xong. Gửi mail lag 800ms, CRM lag 2 giây, thế là user ngồi đợi 3 giây chỉ để đăng ký, trong khi thật ra việc đăng ký nó đã xong ngay lúc lưu DB rồi. Tệ hơn là khi CRM nó sập thì cả cái API đăng ký sập theo luôn, vô lý đúng không, đăng ký với sync CRM thì liên quan gì nhau mà chết chùm.

Queue sinh ra để gỡ đúng mấy cái đó. Nó tách cái producer ra khỏi consumer, nó hấp thụ được spike (kiểu flash sale 10 nghìn đơn một giây mà DB ghi nổi có 1 nghìn, thì queue làm cái hồ chứa), consumer chết thì message nằm chờ chứ không mất, và muốn nhanh thì bơm thêm nhiều consumer chia tải. Nhưng có một cái mình muốn nhấn mạnh vì hồi đầu mình hiểu sai: queue nó không làm tổng công việc của bạn nhanh hơn đâu. Nó chỉ dời thời điểm xử lý lại và tách cái nhịp độ ra thôi. Bạn đang đánh đổi sự đơn giản và tính tức thời để lấy khả năng chịu tải với chống lỗi. Nếu bạn không thực sự cần mấy cái đó thì nhét queue vào chỉ tổ làm hệ thống phức tạp thêm cho vui.

Rồi tới cái mental model mà mình nghĩ là quan trọng nhất, cái này 90% dev hiểu lầm, kể cả mình trước đây: Kafka với RabbitMQ không phải cùng một loại, nó là hai triết lý ngược nhau hoàn toàn. RabbitMQ kiểu broker thông minh consumer ngu, message được đẩy tới consumer, xử lý xong thì ack một cái là message bị xóa khỏi queue luôn, y như cái to-do list, làm xong gạch đi. Còn Kafka thì ngược, broker ngu consumer thông minh, message ghi vào một cái log chỉ-ghi-thêm và không bị xóa sau khi đọc, nó nằm đó theo retention kiểu 7 ngày, consumer tự đọc tự nhớ mình đọc tới đâu bằng cái offset, nhiều nhóm consumer khác nhau đọc cùng một đống dữ liệu mà chẳng đụng nhau, thích thì tua lại đọc từ đầu. Có một câu hỏi mà hỏi xong là phân biệt được ngay hai thằng: "sau khi message xử lý xong nó còn tồn tại không?". RabbitMQ thì không, Kafka thì còn. Chỉ một điểm đó thôi mà nó quyết định gần như mọi thứ phía sau.

Tới đây thì có cú sốc đầu tiên, và mình bị dính chấu thật sự. Khi được hỏi chọn gì cho cái order kia, mình chọn Kafka, với cái lý do nghe rất hợp lý trong đầu: "vì message còn lưu lại nên rollback dễ hơn". Sai. Sai bét nhè luôn. Mà sửa được cái này là một bước nhảy về tư duy chứ không đùa.

Đây nha, giả sử trừ kho ok, thanh toán ok, tới giao vận thì fail. Giờ bạn muốn rollback. Cái message order created vẫn nằm chình ình trong Kafka đó, nó có giúp bạn hoàn lại số kho đã trừ với số tiền đã charge không? Không hề. Vì trừ kho với charge tiền là cái side effect đã xảy ra rồi, ở hệ thống khác rồi, cái log của Kafka nó chỉ là cuốn sổ ghi lại "à việc này từng xảy ra" thôi chứ nó có quyền lực gì mà chui vô DB kho cộng lại số lượng hay gọi sang Stripe đòi tiền về. Mà bạn đọc lại cái message đó (cái này gọi là replay) thì nó chỉ làm quy trình chạy lại từ đầu, tức là trừ kho thêm lần nữa, charge thêm lần nữa. Thảm họa luôn chứ rollback gì.

Cái này mình ghi lại để khỏi quên: replay khác rollback. Replay là phát lại sự kiện để đi tiếp về phía trước. Rollback là hoàn tác cái đã xảy ra. Log nó cho bạn replay chứ nó không cho bạn rollback. Và sự thật phũ phàng là trong hệ phân tán bạn không thể rollback một transaction trải qua nhiều service được. Không có cái BEGIN TRANSACTION ROLLBACK nào ôm nổi cả DB kho lẫn cổng thanh toán lẫn service giao vận đâu.

Vậy người ta làm sao? Người ta dùng Saga, và cái ý tưởng của nó làm mình thấy hơi ngược đời lúc đầu: ta không undo, ta đi tiếp về phía trước bằng một hành động bù trừ, mà bản thân cái hành động bù trừ đó cũng là một sự kiện mới. Trừ kho rồi à, fail à, thì phát một event cộng kho lại. Charge tiền rồi à, fail à, thì phát một event hoàn tiền. Để ý cái này nha, hoàn tiền nó không phải là xóa cái giao dịch charge đi đâu, tiền nó chạy rồi, hoàn tiền là một giao dịch mới toanh, đi tới phía trước, và vô tình làm số dư về như cũ. Khách hàng mở sao kê ra là thấy cả hai luôn, vừa charge vừa refund. Đó mới là sự thật của thế giới phân tán. Có một câu mình đọc được mà thấy đắt: trong microservices không có rollback, chỉ có forward recovery.

Rồi tới một câu hỏi làm mình khựng lại mất một lúc. Kiểu cái email xác nhận đơn hàng nó gửi đi rồi, sau đó thanh toán mới fail, mà email thì làm sao thu hồi được. Lúc đầu mình nghĩ hướng kỹ thuật, nhưng hóa ra lời giải nằm ở chỗ thiết kế quy trình. Một là phân loại lỗi, lỗi tạm thời kiểu timeout mạng chập chờn thì retry vài lần, lỗi vĩnh viễn thì thôi. Hai là đừng hủy ngay, tạo ra một cái trạng thái trung gian kiểu chờ thanh toán, kèm cái timeout, hết giờ mà không trả thì mới đi bù trừ. Ba, và cái này mới là cái hay, là sắp xếp lại thứ tự các bước theo độ khó hoàn tác. Mấy cái hành động không thể hoàn tác như gửi mail hay giao hàng vật lý thì đẩy nó về cuối cùng, sau cái điểm không thể quay đầu. Và chỉ gửi mấy cái email mà dù kết quả thế nào nó vẫn đúng sự thật thôi, kiểu "bạn cần thanh toán để tiếp tục" hay "đơn đã hủy vì không thanh toán", chứ đừng có gửi "đơn đã xác nhận" khi mọi thứ còn chưa chắc.

Tiếp theo là cái nguyên lý mà mình gặp đi gặp lại tới ba lần trong một buổi, lúc đầu còn không nhận ra: idempotency. Bắt đầu từ chỗ "retry thanh toán vài lần", nghe vô hại lắm, nhưng nó chứa một quả mìn kinh điển. Bạn gọi sang cổng thanh toán bảo charge 500k, cổng nó trừ tiền ok rồi, nhưng cái response trên đường về thì bị timeout mất tiêu. Phía bạn nhìn vào chỉ thấy timeout, nghĩ "à lỗi tạm thời, retry thôi", thế là charge thêm phát nữa. Double charge. Vấn đề cốt lõi là khi gặp timeout bạn không bao giờ biết được cái request kia nó đã thực sự xảy ra hay chưa, cái trường hợp "thành công nhưng mất response" với cái trường hợp "thất bại thật" nó nhìn giống hệt nhau từ phía bạn.

Lời giải là cái idempotency key. Bạn gửi kèm một cái key duy nhất, cổng thanh toán nó lưu lại key này ứng với kết quả nào, lần sau thấy lại đúng key đó thì nó lôi kết quả cũ ra trả chứ không xử lý lại. Nhưng có hai cái bẫy nhỏ mà ít người để ý. Một là cái key đó phải ổn định qua mọi lần retry của cùng một thao tác, nghĩa là ba lần retry phải dùng chung một key, chứ lỡ tay mỗi lần retry lại generate một cái UUID mới thì coi như xong phim, mỗi lần là một giao dịch mới, vẫn double charge như thường. Cho nên cái key nó phải dính với ý định nghiệp vụ kiểu payment-orderId ấy, chứ không dính với cái lần thử. Hai là idempotency nó có hai phía, không chỉ phía cổng thanh toán, mà phía bạn nữa, tại vì Kafka với RabbitMQ nó giao hàng kiểu at-least-once, một cái message có thể tới tay consumer của bạn hai lần, nên cái consumer của bạn nó cũng phải tự biết dedupe. Còn nếu cái thằng third party nó không thèm hỗ trợ idempotency key thì sao, thì bạn đổi chiến lược, từ kiểu "bắn rồi thử lại" sang kiểu "hỏi trước rồi mới làm", tức là trước khi retry thì query cái cổng kia xem "giao dịch tham chiếu này của tôi xảy ra chưa". Đây cũng chính là lý do mấy công ty cuối ngày đều có cái quy trình đối soát với ngân hàng, không phải làm cho có đâu, mà là để xử lý đúng cái timeout mơ hồ này đấy.

Xong cái thì tới một ngã ba kiến trúc khá lớn, và mình lại bị dính cái bẫy trực giác mà nghe nói tới 70% người mắc. Lúc này cái lời giải của mình nó đã phình ra thành một cái máy trạng thái có nhớ, có timeout, có rẽ nhánh rồi. Câu hỏi là ai đứng ra điều phối cái đống đó. Có hai trường phái. Một là choreography, không có nhạc trưởng, mỗi service tự nghe event tự phản ứng tự phát event tiếp. Hai là orchestration, có một thằng nhạc trưởng trung tâm nắm cả cái flow.

Trực giác của mình lúc đó là, flow càng phức tạp nhiều rẽ nhánh thì càng nên chọn choreography, vì mỗi service tự lo việc của nó thì code sạch dễ hiểu dễ mở rộng. Nghe hợp lý đúng không. Nhưng nó ngược. Càng phức tạp nhiều nhánh thì choreography càng tệ. Lý do là vì với choreography thì không tồn tại một chỗ nào mô tả cái "quy trình đặt hàng là gì" cả, nó bị xé nhỏ ra rải khắp tám chín cái service, chỉ tồn tại ngầm trong cái mạng nhện "thằng nào subscribe event của thằng nào". Muốn hiểu cả cái flow thì phải mở hết các service ra đọc rồi ngồi tự mô phỏng trong đầu xem event nó chảy đi đâu. Cái mình tưởng là "dễ hiểu" thật ra chỉ là dễ hiểu từng mảnh chứ bất khả hiểu toàn cục. Và cái "decoupled" đó là ảo giác thôi, các service vẫn dính nhau qua thứ tự event, chỉ là cái sự dính đó bị giấu đi không nhìn thấy trong code.

Cho dễ hình dung thì kiểu thế này, sếp bảo: đơn trên 10 triệu thì chèn thêm bước kiểm tra gian lận vào giữa thanh toán với giao vận. Nếu là orchestration thì bạn mở cái máy trạng thái ra, thêm một node fraud check vào giữa, thêm một nhánh điều kiện nếu lớn hơn 10 triệu, sửa đúng một chỗ là xong, mà bản thân cái máy trạng thái đó nó chính là tài liệu sống của quy trình luôn. Còn nếu là choreography thì rối hơn nhiều, hiện tại thằng payment phát event PaymentCompleted thì thằng shipping nghe rồi giao, giờ muốn chèn fraud vào giữa thì phải bắt fraud nghe PaymentCompleted, rồi phải sửa cả thằng shipping để nó đổi sang nghe FraudPassed thay vì PaymentCompleted, mà thằng shipping nó liên quan quái gì tới fraud đâu mà tự nhiên phải sửa nó, rồi lo thứ tự, lo trường hợp đơn dưới 10 triệu thì fraud im lặng cho qua, và cuối cùng chẳng có chỗ nào ghi lại "à quy trình mới giờ nó như vầy" cả.

Còn cái nỗi lo phổ biến là orchestration thì có một thằng trung tâm, single point of failure, dễ quá tải. Cái này mình từng nghĩ vậy nhưng phần lớn là lầm tưởng. Cái orchestrator nó là nhạc trưởng chứ không phải nhân công, việc nặng vẫn nằm ở các service, nó chỉ điều phối thôi nên bảo nó quá tải là hơi thổi phồng. Mà cái state của nó nằm trong DB chứ không nằm trong RAM, nên bạn chạy nhiều cái instance song song scale ngang thoải mái, hết single point of failure. Nói orchestrator là điểm chết duy nhất thì cũng như nói cái DB của tôi là điểm chết duy nhất vậy, đúng về mặt kỹ thuật nhưng người ta giải quyết bằng HA với replication chứ không phải bằng cách vứt cái DB đi. Mà cả một thế hệ công cụ sinh ra để làm đúng cái việc orchestrator này cho chuẩn luôn rồi, Temporal, AWS Step Functions, Camunda, Netflix Conductor, mấy hệ thống tỷ đô xài ầm ầm chứ có sợ đâu. Cho nên cái heuristic đúng là, flow phức tạp nhiều nhánh hay đổi cần nhìn rõ kiểm soát thì orchestration, còn mấy phản ứng rời rạc song song không có quy trình gì kiểu order tạo xong thì độc lập đẩy analytics với đánh index search với gửi mail thì choreography, và thực tế ngon nhất là lai hai cái, orchestrate cái lõi giao dịch quan trọng còn choreograph mấy thứ ngoại vi.

Rồi tới cú sốc cuối, cái này mình thích nhất. Cái nỗi lo orchestrator chết của mình hóa ra không sai, chỉ là đặt nhầm chỗ. Vấn đề thật không phải nó quá tải, mà là cái này: orchestrator đang chạy nửa chừng, charge xong rồi, chưa kịp gọi shipping thì nó crash. Sống dậy thì làm sao biết đơn này đang ở bước nào để đi tiếp cho đúng. Mình đề xuất hướng là định nghĩa status cho từng bước, sau mỗi bước thành công thì cập nhật status, rồi có một cái background job quét mấy đơn dang dở để xử lý tiếp. Đúng hướng, nhưng có một cái vực thẳm nằm ngay đó.

Soi từng nano giây nha. Bước một, gọi charge, cổng trừ tiền ok. Crash ngay tại đây. Bước hai, định ghi status bằng PAID, chưa kịp chạy. Sống dậy thì DB vẫn ghi là đang chờ thanh toán, cái job nó thấy "à đơn này chưa trả tiền" thế là gọi charge lần nữa, double charge. Mà bạn đảo ngược thứ tự lại, ghi status trước charge sau, thì chết kiểu khác, ghi PAID xong rồi crash trước khi charge, đơn ghi là đã trả mà thực ra chưa hề trừ đồng nào, thất thoát.

Đây là cái sự thật nền tảng mà mình nghĩ ai làm hệ phân tán cũng phải thấm: bạn không thể nào làm cái side effect bên ngoài với cái việc ghi status trong DB chung một transaction nguyên tử được, vì chúng nằm ở hai hệ thống khác nhau. Luôn luôn tồn tại một cái khe nứt giữa "đã làm" và "đã ghi lại là đã làm", và cái khe đó bạn không bao giờ đóng kín được. Hệ quả là gì, là lưu status nó chỉ thu hẹp cái cửa sổ lỗi lại thôi chứ không xóa được nó, và vì cái khe nứt là bất khả tiêu diệt nên cái recovery của bạn bắt buộc phải idempotent. Thấy chưa, idempotency nó lại quay về, lần thứ ba trong một buổi, ở ba chỗ tưởng chừng chẳng liên quan gì nhau là retry thanh toán, dedupe ở consumer, và recovery sau crash. Một cái thứ mà cứ xuất hiện đi xuất hiện lại như vậy thì nó không phải mẹo vặt đâu, nó là nguyên lý nền tảng.

Có hai cái tinh chỉnh để biến cái ý tưởng thô của mình thành chuẩn công nghiệp. Một là ghi ý định trước ghi kết quả sau, đừng đợi thành công mới ghi, mà trước khi charge thì ghi luôn cái trạng thái kiểu đang thử thanh toán kèm cái idempotency key đã sinh sẵn, xong rồi mới ghi PAID, nhờ vậy lúc recovery nó thấy cái trạng thái đang thử là biết "à mình đã bắt đầu việc này rồi, lấy đúng cái key đó retry cho an toàn", cái này đúng y tư duy Write-Ahead Log trong database. Hai là cái job recovery phải lo chuyện tranh chấp, hai cái instance cùng quét trúng một đơn là loạn, nên phải khóa lại, SELECT FOR UPDATE hay leasing gì đó.

Và cái twist hay nhất là, tất cả những thứ mình vừa hì hục nghĩ ra đó, lưu state từng bước rồi recovery rồi write-ahead rồi idempotent retry, nó chính là cái Temporal nó làm sẵn cho bạn rồi. Cách nó làm là ghi lại lịch sử kết quả của từng bước, kiểu event-sourced, khi crash sống dậy nó chạy lại cái code workflow nhưng bước nào đã xong thì nó trả luôn kết quả đã lưu chứ không làm lại, thế là nó tua về đúng chỗ dang dở rồi đi tiếp như chưa hề crash. Bài học rút ra cho dân định làm architect như mình là, khi nào thấy mình đang ngồi tự tay code lại một cái máy trạng thái bền bỉ có recovery, thì đó là dấu hiệu rõ ràng là mình đang phát minh lại cái bánh xe, nên cân nhắc xài luôn một cái durable execution engine. Tất nhiên là không có bữa trưa miễn phí đâu, xài Temporal thì lại đẻ thêm một cục hạ tầng phải nuôi.

Ngồi nhìn lại thì hơi giật mình, chỉ từ một câu hỏi Kafka hay RabbitMQ mà mình đi qua một mạch dài: queue với log khác nhau ra sao, rồi saga, rồi cái chuyện không có rollback chỉ có forward recovery, rồi compensating action, rồi sắp xếp các bước theo độ khó hoàn tác, rồi idempotency xuất hiện tới ba lần, rồi orchestration với choreography và câu hỏi quy trình sống ở đâu, rồi cuối cùng là durable execution với cái khe nứt không bao giờ đóng được. Cái sợi chỉ xuyên suốt mà mình mang về là thế này: trong hệ phân tán thì mọi thứ đều có thể fail ở giữa chừng, và hai hệ thống thì không bao giờ đồng ý với nhau một cách nguyên tử, cho nên mình không chống lỗi bằng cách ngăn không cho nó xảy ra, mà bằng cách thiết kế sao cho mọi thao tác có thể lặp lại an toàn và phục hồi tiến tới.

Còn câu hỏi Kafka hay RabbitMQ á, mình vẫn chưa trả lời đâu nha ;)) mà thấy cũng hay, hóa ra hỏi đúng câu nó còn quan trọng hơn là trả lời nhanh một câu. Hẹn ae bài sau, lúc đó mình đóng lại cái vòng tròn này, kể chuyện khi nào nên dùng Kafka, khi nào dùng RabbitMQ, và khi nào thì tốt nhất là đừng có dùng queue cho mệt.

Trước hết, rate limit để làm gì. Không chỉ để chặn mấy ông spam. Nó bảo vệ hệ thống khỏi bị quá tải, chống abuse và brute-force, đảm bảo công bằng giữa các user để một thằng không ngốn hết tài nguyên của cả đám, và kiểm soát chi phí khi bạn gọi API bên thứ ba tính tiền theo lượt. Nói cách khác, nó là một cái van bảo vệ, không phải chỉ là cái khóa cửa.

Giờ tới phần cốt lõi: các thuật toán. Mình đi từ đơn giản tới tinh tế.

Đầu tiên là Fixed Window, cửa sổ cố định. Ý tưởng dễ nhất: mỗi phút cho 100 request, lưu một counter cho mốc phút đó, mỗi request tới thì tăng lên một, quá 100 thì chặn, hết phút thì reset. Trên Redis mình làm bằng một key kiểu user:123:minute với lệnh INCR, và set TTL một phút. Có một cái bẫy nho nhỏ mà nhiều người dính: phải set TTL đúng lúc tạo key, tức là khi INCR trả về 1 thì mới EXPIRE, chứ nếu lần nào cũng EXPIRE thì key không bao giờ hết hạn. Cách này nhẹ và nhanh, nhưng nó có một lỗ hổng kinh điển gọi là boundary burst: nếu user bắn 100 request vào giây cuối của phút này và thêm 100 request vào giây đầu của phút sau, thì trong vòng hai giây họ đẩy được 200 request, gấp đôi giới hạn, dù về mặt sổ sách thì mỗi phút vẫn đúng 100. Chính cái lỗ hổng này đẻ ra các thuật toán tiếp theo.

Để vá nó, có Sliding Window Log, cửa sổ trượt kiểu ghi log. Thay vì đếm theo mốc phút cứng, mình lưu timestamp của từng request, và mỗi khi có request mới thì đếm xem trong đúng 60 giây vừa qua tính tới hiện tại có bao nhiêu cái. Trên Redis mình dùng Sorted Set, score chính là timestamp. Luồng xử lý là: xóa hết các phần tử cũ hơn 60 giây bằng ZREMRANGEBYSCORE, đếm số còn lại bằng ZCARD, nếu dưới ngưỡng thì ZADD thêm request mới vào và set EXPIRE. Cách này chính xác tuyệt đối, không còn burst ở biên. Cái giá là tốn bộ nhớ, vì phải lưu từng timestamp một, user nào bắn nhiều thì Sorted Set phình to.

Đứng giữa hai cái trên là Sliding Window Counter, một kiểu xấp xỉ rất khéo. Nó không lưu từng request, mà giữ counter của cửa sổ hiện tại và cửa sổ trước, rồi ước lượng theo tỉ lệ phần đã trôi qua của cửa sổ hiện tại. Ví dụ đang ở giây thứ 15 của phút mới, nó lấy toàn bộ counter phút này cộng với 75% counter phút trước. Nó gần như chính xác bằng sliding log nhưng tốn bộ nhớ chỉ bằng fixed window. Đây là lựa chọn rất thực dụng cho hệ thống lớn, và là cách Cloudflare từng chia sẻ họ dùng.

Tới đây là hai thuật toán mình thích nhất vì nó đổi hẳn góc nhìn, không còn là "đếm request" nữa mà là "mô hình hóa dòng chảy".

Token Bucket, cái xô đựng token. Tưởng tượng một cái xô có sức chứa tối đa, ví dụ 100 token, và cứ mỗi giây hệ thống rót thêm vào đó, ví dụ 10 token một giây, đầy thì thôi. Mỗi request muốn đi qua phải lấy một token; còn token thì đi, hết thì bị chặn. Cái đẹp của nó là cho phép burst một cách có kiểm soát: lúc rảnh xô đầy dần lên, nên khi có một đợt cao điểm ngắn, user có thể tiêu một lúc tới 100 request, sau đó thì bị ghì lại đúng theo tốc độ rót 10 mỗi giây. Một mẹo cài đặt hay là không cần một con worker chạy nền rót token thật, mà dùng lazy refill: chỉ lưu số token còn lại và thời điểm chạm cuối, khi có request mới tới thì tính xem từ lúc đó tới giờ trôi qua bao lâu, nhân với tốc độ rót để biết nên cộng thêm bao nhiêu token, tất nhiên không vượt sức chứa. Cách này rất phổ biến, AWS hay nhiều API gateway dùng nó vì nó vừa giới hạn tốc độ trung bình vừa thân thiện với traffic thật vốn hay giật cục.

Người anh em của nó là Leaky Bucket, cái xô rỉ nước. Cũng là cái xô, nhưng lần này request đổ vào và chảy ra ở một tốc độ cố định, đều như nhỏ giọt, xô đầy thì request mới bị tràn ra ngoài tức là bị chặn. Khác biệt cốt lõi so với token bucket là token bucket cho phép burst còn leaky bucket thì làm phẳng dòng chảy, đầu ra luôn đều tăm tắp. Cho nên leaky bucket hợp với những chỗ cần traffic shaping, cần bảo vệ một hệ thống phía sau vốn chỉ chịu được tốc độ ổn định chứ không chịu nổi giật cục, ví dụ đẩy message vào một con service mong manh. Chọn token hay leaky thực ra là chọn: mình muốn cho phép bùng nổ ngắn hạn, hay muốn dòng ra thật mượt.

Chọn xong thuật toán rồi thì tới phần mà mình thấy mới là chỗ phân biệt người làm hệ thống thật với người đọc lý thuyết: làm sao cho nó đúng trong môi trường phân tán.

Vấn đề đầu tiên là atomicity. Để ý mấy thuật toán trên đều gồm nhiều bước: đọc giá trị, kiểm tra ngưỡng, rồi ghi lại. Nếu hai request của cùng một user đập vào hai server khác nhau cùng một lúc, cả hai cùng đọc thấy 99, cả hai cùng nghĩ "còn chỗ", cả hai cùng cho đi, thế là vượt ngưỡng. Đây đúng là race condition kinh điển. Và đây là chỗ Redis tỏa sáng: vì Redis xử lý lệnh trên một luồng duy nhất, nên nếu mình gói cả cụm đọc-kiểm tra-ghi vào một Lua script, Redis sẽ chạy trọn vẹn đoạn đó mà không cho lệnh nào chen ngang. Toàn bộ logic rate limit trở thành một thao tác nguyên tử. Cái tính single-thread mà người ta hay nói là điểm yếu, ở đây lại biến thành siêu năng lực. Mình thấy đây là một ví dụ rất đẹp cho thấy hiểu sâu một công cụ thì sẽ tận dụng được những thứ tưởng như nghịch lý.

Vấn đề thứ hai là thời gian. Nhiều thuật toán dựa vào timestamp, mà nếu mỗi server lấy giờ máy của nó thì đồng hồ lệch nhau vài trăm mili giây là chuyện thường, gọi là clock skew, và rate limit sẽ sai. Cách xử lý gọn là đừng tin đồng hồ của application server, hãy lấy thời gian từ chính Redis bằng lệnh TIME, để mọi quyết định cùng quy về một nguồn thời gian duy nhất.

Vấn đề thứ ba là khi chính cái Redis làm rate limit bị sự cố thì sao. Lúc đó mình phải chọn một trong hai triết lý. Fail-open nghĩa là nếu không kiểm tra được thì cứ cho request đi, ưu tiên giữ dịch vụ sống, chấp nhận rủi ro bị vượt giới hạn trong lúc Redis chết. Fail-close thì ngược lại, không kiểm tra được thì chặn hết, ưu tiên bảo vệ hệ thống phía sau bằng mọi giá. Không có đáp án đúng tuyệt đối, nó tùy bài toán: API public chống abuse thì có khi chọn fail-close, còn một tính năng phụ không muốn làm gián đoạn trải nghiệm thì fail-open. Điều quan trọng là phải chọn có ý thức, chứ đừng để nó xảy ra ngẫu nhiên.

Cuối cùng là phần giao tiếp với client, đừng quên. Khi chặn, đừng trả về một lỗi 500 chung chung, hãy trả đúng mã 429 Too Many Requests, kèm header Retry-After để client biết chờ bao lâu thì thử lại, và nên kèm các header kiểu X-RateLimit-Remaining để client tự điều tiết. Một cái rate limiter tử tế không chỉ biết nói không, nó còn nói cho đối phương biết khi nào thì được nói có.

À, và có một thứ dễ nhầm mà mình muốn tách bạch: rate limiting không phải là load shedding. Rate limiting là giới hạn theo từng chủ thể, kiểu mỗi user mỗi key được bao nhiêu, mang tính công bằng và hợp đồng. Còn load shedding là khi cả hệ thống đang ngộp thì chủ động vứt bớt request bất kể của ai để tự cứu mình. Một cái là luật chơi định trước, một cái là phản ứng khẩn cấp. Hệ thống trưởng thành thường có cả hai.

Ngồi viết lại hết, mình rút ra điều này: rate limiter nhìn thì nhỏ nhưng nó ép mình chạm vào gần như mọi chủ đề cốt lõi của hệ thống phân tán, từ race condition, atomicity, đồng bộ thời gian, cho tới triết lý xử lý khi sự cố. Chọn thuật toán chỉ là bề nổi; phần chìm là bạn hiểu hệ thống của mình chịu được kiểu traffic nào, cần burst hay cần mượt, ưu tiên sống sót hay ưu tiên bảo vệ. Trả lời được mấy câu đó thì mới gọi là thiết kế, còn lại chỉ là gắn thư viện.

Mình cũng mới hiểu tới mức này thôi, ae nào làm sâu hơn thì bổ sung, hay muốn mình đào kỹ phần nào cứ comment. Mình sẽ viết tiếp các chủ đề khác trên hành trình ôn lên architect.

Trước hết phải nói rõ một điều: cache có ở khắp mọi nơi trong cái stack của chúng ta, từ CPU cache, browser cache, CDN, cache ở API gateway, cho tới cache ở tầng application. Mỗi tầng giải một bài toán khác nhau. Nhưng phần mình kể hôm nay tập trung vào cái mà dân backend đụng nhiều nhất: application-level cache, kiểu đặt Redis trước database để gánh traffic đọc.

Bắt đầu từ pattern phổ biến nhất, gọi là Cache-Aside hay Lazy Loading. Luồng đọc thế này: request tới, ngó vào cache trước, có thì trả về luôn (cache hit), không có thì xuống database lấy, nhét vào cache rồi mới trả về (cache miss). Còn luồng ghi, khi dữ liệu thay đổi, thì có một chi tiết tinh tế mà nhiều người làm sai: nên XÓA key trong cache, chứ đừng UPDATE lại cache. Lý do là nếu hai request ghi xảy ra gần như đồng thời, thứ tự update cache có thể bị đảo, khiến cache giữ lại giá trị cũ dù database đã là giá trị mới. Còn nếu chỉ xóa, thì lần đọc kế tiếp luôn lấy giá trị mới nhất từ DB. Cái giá phải trả chỉ là một lần cache miss, rẻ hơn nhiều so với việc ôm dữ liệu sai.

Tiếp theo là một bài học mình từng xem nhẹ: TTL là bắt buộc, kể cả khi bạn đã chủ động xóa cache mỗi lần ghi. Tại sao? Vì việc "xóa cache khi có thay đổi" dựa vào event, mà event thì có thể miss, có thể bug, có thể bị mất. Nếu một event xóa bị lọt, cache của bạn sẽ stale vĩnh viễn. TTL chính là lưới an toàn cuối cùng, đảm bảo dù có sai thì cũng chỉ sai trong vài giây hoặc vài phút rồi tự sửa, chứ không bao giờ sai mãi mãi.

Rồi tới bộ ba vấn đề kinh điển mà hồi xưa mình không hề biết tên, nhưng thực ra đã từng gặp ngoài production. Thứ nhất là cache penetration, tức là query những thứ KHÔNG tồn tại. Ai đó cứ spam query một id không có trong DB, cache miss liên tục, mỗi lần lại dội xuống database, mà database cũng không có gì để trả nên chẳng cache được gì, vòng lặp đó bào chết DB. Cách xử lý là cache luôn cả kết quả rỗng với TTL ngắn, hoặc dùng Bloom filter để chặn từ đầu những id chắc chắn không tồn tại.

Thứ hai là cache avalanche, tuyết lở. Tưởng tượng bạn nạp một triệu sản phẩm vào cache cùng một lúc với TTL y hệt nhau là một giờ. Đúng một giờ sau, tất cả hết hạn cùng một khoảnh khắc, toàn bộ traffic đổ ụp xuống database trong một giây, và DB sập. Cách chữa đơn giản mà hiệu quả: thêm một khoảng random vào TTL, để các key hết hạn rải đều ra thay vì dồn cục.

Thứ ba là cache breakdown, hay còn gọi là hot key. Một sản phẩm đang hot, ví dụ đang flash sale, có mấy chục nghìn request mỗi giây. Đúng cái giây nó hết hạn, hàng nghìn request cùng miss một lúc, cùng lao xuống DB query đúng một dòng dữ liệu, hiện tượng này gọi là thundering herd. Cách xử lý là dùng một cái lock, chỉ cho duy nhất một request đi load DB rồi nạp lại cache, đám còn lại chờ một chút; hoặc dùng logical expiration, tức là không để key hết hạn cứng mà có một worker nền âm thầm refresh.

Nhưng phần làm mình tâm đắc nhất, và cũng là phần khó nhất, là chuyện nhất quán giữa cache và database. Câu hỏi nghe thì đơn giản: khi cập nhật dữ liệu, nên ghi database trước rồi xóa cache, hay xóa cache trước rồi ghi database? Mình từng nghĩ xóa cache trước an toàn hơn, vì nếu ghi DB lỗi thì cùng lắm tốn một cache miss. Nhưng đó mới chỉ là một nửa câu chuyện. Cái nửa quan trọng hơn là chuyện hai request chạy đồng thời. Nếu xóa cache trước rồi mới ghi DB, sẽ có một cửa sổ thời gian khá rộng giữa hai bước đó, và một request đọc chen vào đúng lúc này sẽ đọc được giá trị CŨ từ DB rồi nạp ngược nó vào cache. Kết quả là cache stale mà chẳng còn event nào tới xóa nó nữa. Ngược lại, nếu ghi DB trước rồi xóa cache sau, cửa sổ stale do đọc đồng thời hẹp hơn nhiều, vì thao tác ghi thường chậm hơn thao tác đọc. Đó là lý do khuyến nghị chuẩn của ngành là ghi DB trước, xóa cache sau, dù nghe có vẻ ngược trực giác.

Mà kể cả chọn đúng thứ tự thì vẫn còn khe hở nhỏ. Để vá triệt để, người ta dùng vài lớp: TTL làm nền, rồi delayed double delete tức là xóa cache, ghi DB, chờ một chút rồi xóa cache lần nữa để dọn sạch dữ liệu cũ mà một request đọc có thể đã kịp nạp vào; nếu lệnh xóa cache thất bại thì đẩy vào retry queue chứ không bỏ qua; và cao cấp nhất là dùng CDC, đọc binlog của database bằng công cụ như Debezium, hễ DB thay đổi thật là tự động phát đi để xóa cache, đảm bảo không miss và tách hẳn khỏi business code.

Tới đây thì mình có một khoảnh khắc vỡ òa: bài toán "ghi DB rồi xóa cache" thực ra CHÍNH LÀ cái Dual Write Problem mà mình từng gặp khi làm việc với message queue. Lại là chuyện ghi vào hai hệ thống mà không có transaction chung. Và vì bản chất giống nhau, nên lời giải cũng giống nhau: đừng tự ghi tay vào hai nơi trong code, hãy để một nguồn sự thật duy nhất, thường là log của database, làm gốc để đồng bộ cái còn lại. Khi nhận ra cùng một bài toán nấp dưới nhiều lớp vỏ khác nhau, mình thấy mình bắt đầu tư duy giống một architect hơn.

Một bài học nữa về tư duy: không phải dữ liệu nào cũng nên cache như nhau. Tên sản phẩm, mô tả, hình ảnh thì gần như không đổi, cứ cache TTL dài thoải mái. Giá thì đổi thỉnh thoảng, cache vừa phải và xóa khi có thay đổi. Nhưng tồn kho thì khác hẳn, nó đổi liên tục và cần chính xác. Với tồn kho, mình tách làm hai mức: con số hiển thị trên màn hình danh sách thì không cần chính xác tuyệt đối, cache TTL vài giây, chấp nhận hơi cũ; nhưng lúc khách bấm chốt đơn và trừ kho thật thì TUYỆT ĐỐI không quyết định dựa trên cache, mà đi thẳng vào nguồn sự thật bằng một thao tác atomic, vì bán quá số lượng (oversell) là lỗi không được phép. Cache là để tăng tốc đọc, không phải để quyết định những nghiệp vụ cần chính xác từng đơn vị.

Phần cuối, mình muốn nói riêng về Redis, vì nhiều người (có cả mình ngày xưa) chỉ coi nó là cái kho key-value cho nhanh, trong khi nó thực ra là một data structure server. Nó có Hash để lưu object theo từng field, nên bạn update đúng một field tồn kho mà không phải ghi lại cả object. Có Sorted Set để làm leaderboard hay rate limiter. Có HyperLogLog đếm số lượng unique xấp xỉ hàng tỷ phần tử chỉ tốn mười mấy KB. Có Bitmap, có Geo để tìm theo bán kính, có Stream làm hàng đợi. Biết chọn đúng cấu trúc cho đúng bài toán là một nửa sức mạnh của Redis.

Còn vài thứ về Redis mà mình thấy nên nắm để hiểu sâu. Khi RAM đầy, Redis phải quyết định xóa key nào, đó là eviction policy, và bạn nên phân biệt LRU (xóa cái lâu rồi không dùng) với LFU (xóa cái ít được dùng thường xuyên) tùy theo access pattern của mình. Redis xử lý lệnh trên một luồng duy nhất, đó là lý do nó nhanh và cũng là lý do tuyệt đối tránh các lệnh nặng như KEYS trên production. Nhưng cái tính single-thread đó lại biến thành siêu năng lực khi bạn cần atomic: gói một đoạn logic vào Lua script, Redis sẽ chạy trọn vẹn đoạn đó mà không cho lệnh nào chen vào, nhờ vậy mà những thứ như rate limiter hay trừ kho mới chống được race condition giữa hàng nghìn server. Về độ bền thì Redis có RDB (chụp snapshot, gọn, restore nhanh, nhưng mất dữ liệu giữa hai lần chụp) và AOF (ghi log mọi lệnh, bền hơn nhưng nặng hơn), production thường bật cả hai. Và khi một con Redis không gánh nổi nữa thì có replication để scale đọc, sentinel để tự động failover, và cluster để sharding dữ liệu ra nhiều node.

Ngồi viết lại hết những thứ này, mình nhận ra điều quan trọng nhất không phải là từng kỹ thuật riêng lẻ, mà là cách nhìn: caching không bao giờ miễn phí. Mỗi lần bạn thêm một lớp cache, bạn đổi tốc độ lấy sự phức tạp về nhất quán. Việc của một người làm hệ thống không phải là cache thật nhiều cho nhanh, mà là biết cache cái gì, cache bao lâu, chấp nhận sai lệch tới đâu, và chỗ nào thì tuyệt đối không được tin vào cache. Hiểu được ranh giới đó, theo mình, mới là cái phân biệt một người biết dùng Redis với một người thiết kế được hệ thống.

Mình cũng mới hiểu ở mức này thôi, ae nào rành hơn thì bổ sung, hay muốn mình đào sâu phần nào cứ comment nhé. Mình sẽ viết tiếp các chủ đề khác trên hành trình ôn lên architect này.

Mọi chuyện bắt đầu từ câu hỏi kinh điển: "có nên tách monolith ra microservices không?". Hồi xưa mình sẽ trả lời kiểu "tách đi cho hiện đại", nhưng giờ mình hiểu câu hỏi đúng phải là "vấn đề thực sự đang là gì?". Microservices thật ra chỉ giải quyết đúng 3 thứ: scale độc lập, release nhanh hơn, và cô lập lỗi. Nếu cái đau của bạn không nằm ở 3 chỗ đó thì nhiều khi một modular monolith gọn gàng còn rẻ hơn nhiều. Architect là người bắt đầu từ problem, không phải bắt đầu từ solution.

Nhưng đời không cho không cái gì. Tách microservices xong là mất luôn transaction. Hồi còn monolith, trừ tiền + trừ kho + tạo đơn nằm gọn trong một transaction, lỗi cái là rollback sạch sẽ. Tách ra, mỗi service một database riêng, giờ khách đặt hàng mà trừ tiền thành công nhưng trừ kho fail thì sao, chẳng lẽ để khách mất tiền oan? "biết là phải xử lý nhưng lúc đầu nghĩ mãi không ra cách cho đẹp" 😀

Cái tên đầu tiên hiện ra trong đầu là 2PC (Two-Phase Commit), kiểu transaction phân tán trong sách giáo khoa. Nghe thì hay, nó hứa nhất quán tức thì. Nhưng đào kỹ mới thấy cái giá của nó: khóa tài nguyên kéo dài chờ tất cả các bên, mà chỉ cần ông coordinator điều phối chết giữa chừng là cả đám kẹt cứng giữ lock vô thời hạn. Nói cách khác 2PC đánh đổi tính sẵn sàng và khả năng scale để lấy nhất quán, mà đây lại đúng là 2 thứ microservices không thể hy sinh. Thế là loại.

Lời giải thực tế là Saga. Thay vì một transaction to đùng, người ta dùng một chuỗi giao dịch nhỏ, bước nào lỗi thì chạy một giao dịch bù trừ để hoàn tác cái đã làm. Có một mẹo mình thấy rất hay: thanh toán thật không trừ tiền ngay, mà giữ tiền trước (authorize) rồi mới trừ thật (capture) khi mọi bước đều ổn. Nhờ vậy lúc lỗi chỉ cần nhả tiền ra, khách không mất một xu.

Đào tiếp tới Saga thì đụng ngay CAP theorem, và đây là chỗ mình từng hiểu sai bao năm. Ai cũng thuộc lòng câu "chọn 2 trong 3", nhưng sự thật là cái Partition (mạng đứt) nó là thứ bắt buộc phải chấp nhận, vì mạng thì chắc chắn sẽ có lúc lỗi. Nên lựa chọn thật sự chỉ còn là: khi mạng đứt, bạn hy sinh nhất quán hay hy sinh tính sẵn sàng. Mà tiện thể, chữ C trong CAP với chữ C trong ACID là hai thứ hoàn toàn khác nhau, hồi xưa mình cứ tưởng là một ;))

Rồi tới một cái bug kinh điển mà rất nhiều người mắc mà không biết, gọi là Dual Write Problem. Service làm xong việc thì phải phát event để báo cho bước sau, nhưng ghi vào database và phát event lên message broker là hai hệ thống khác nhau, không có transaction nào bao trùm cả hai. Crash ngay khe hở giữa hai bước đó là dữ liệu lệch nhau ngay. Lời giải là Outbox pattern: ghi luôn cái event vào chung database trong cùng một transaction với dữ liệu nghiệp vụ, rồi để một tiến trình riêng đọc ra và phát đi sau. Đơn giản mà thông minh.

Và mảnh ghép cuối cùng là idempotency, cái này thì quá quen với ae backend. Trong hệ phân tán không bao giờ đảm bảo được "exactly-once", client retry, broker gửi trùng, Saga thử lại, đủ kiểu khiến cùng một lệnh chạy nhiều lần. Cách xử lý là idempotency key: client gửi kèm một id duy nhất, server thấy trùng thì trả lại kết quả cũ thay vì làm lại từ đầu, nhờ vậy không bao giờ trừ tiền khách hai lần. Đây cũng chính là lý do Stripe hay PayPal đều có cái header Idempotency-Key.

Điều làm mình tâm đắc nhất không phải từng món riêng lẻ, mà là khi xâu chuỗi lại: tách microservices nên mất transaction, mất transaction nên cần Saga, Saga thì dính eventual consistency nên phải hiểu CAP, Saga cần phát event an toàn nên cần Outbox, Outbox gửi trùng nên phải có Idempotency. Hóa ra không phải 6 chủ đề rời rạc để học vẹt, mà là một câu chuyện logic nối liền nhau. Và mình nghĩ đó mới đúng là thứ phân biệt một người biết keyword với một người thực sự hiểu hệ thống.

Mình khuyến khích bạn đọc thêm các bài viết gốc để hiểu sâu hơn.

Agent là gì?

“Agent” có thể được định nghĩa theo nhiều cách. Mỗi công ty có một định nghĩa riêng:

“Agent là các hệ thống hoàn thành nhiệm vụ một cách độc lập thay cho bạn.” — OpenAI

“Ở dạng cơ bản nhất, một Agent AI tạo sinh có thể được định nghĩa là một ứng dụng cố gắng đạt được mục tiêu bằng cách quan sát thế giới và hành động dựa trên nó sử dụng các công cụ có sẵn. Agent có tính tự chủ và có thể hành động độc lập mà không cần sự can thiệp của con người.” — Google

“Tại Anthropic, chúng tôi phân loại tất cả các biến thể này thành hệ thống agentic, nhưng phân biệt rõ ràng về kiến trúc giữa workflow (hệ thống được điều phối theo luồng code định sẵn) và agent (hệ thống mà LLM tự động điều khiển quy trình và sử dụng công cụ).” — Anthropic

Dù định nghĩa khác nhau, cả ba đều đồng ý rằng agent:

• Hoạt động tự chủ để thực hiện nhiệm vụ

• Tự đưa ra quyết định về bước tiếp theo

• Sử dụng công cụ để đạt mục tiêu

Ba thành phần chính của một Agent

• Model: Mô hình ngôn ngữ tạo ra output

• Instructions / Orchestration: Hướng dẫn và quy tắc định nghĩa cách agent hoạt động

• Tools: Cho phép agent tương tác với dữ liệu và dịch vụ bên ngoài

1. Model — Mô hình ngôn ngữ

Model (mô hình) chính là mô hình ngôn ngữ (Language Model). Nói đơn giản, nó dự đoán từ hoặc chuỗi từ tiếp theo dựa trên những từ đã thấy trước đó.

Agent khác Model như thế nào?

Agent và model không phải là một. Model chỉ là một thành phần bên trong agent. Trong khi model bị giới hạn ở việc dự đoán phản hồi dựa trên dữ liệu huấn luyện, agent mở rộng khả năng này bằng cách hành động độc lập để đạt mục tiêu cụ thể.

Large Language Models (LLM) — Mô hình ngôn ngữ lớn

Chữ “Large” trong LLM chỉ số lượng tham số (parameters) mà mô hình được huấn luyện. Các mô hình này có thể có hàng trăm tỷ hoặc thậm chí hàng nghìn tỷ tham số, được huấn luyện trên lượng dữ liệu khổng lồ và cần sức mạnh tính toán rất lớn.

Ví dụ LLM: GPT-5o, Gemini Pro 2.5, Claude 4.6 Sonnet.

Small Language Models (SLM) — Mô hình ngôn ngữ nhỏ

SLM được sử dụng cho các tác vụ đơn giản hơn, cần ít dữ liệu và tham số hơn, nhẹ hơn khi chạy và dễ kiểm soát hơn. SLM thường có dưới 10 tỷ tham số, giảm đáng kể chi phí tính toán và năng lượng.

Ví dụ SLM: Llama 3.1 8B (Meta), Gemma2 9B (Google), Mistral 7B (Mistral AI).

Open Source vs Closed Source

Bạn có thể tìm các mô hình open source trên Hugging Face.

2. Instructions / Orchestration — Hướng dẫn và điều phối

Instructions là các hướng dẫn và rào chắn rõ ràng định nghĩa cách agent hoạt động. Google gọi thành phần này là “Orchestration” (điều phối), bao gồm ba lớp:

• Instructions — Hướng dẫn cụ thể

• Memory — Bộ nhớ

• Model-based Reasoning/Planning — Suy luận và lập kế hoạch

Orchestration tuân theo một mô hình tuần hoàn: agent thu thập thông tin, xử lý nội bộ, rồi sử dụng kết quả để xác định bước tiếp theo.

2.1 Instructions — Hướng dẫn

Instructions có thể bao gồm mục tiêu, hồ sơ, vai trò, quy tắc, và thông tin bạn cho là quan trọng để nâng cao hành vi của model.

system_prompt = """
You are a friendly and a programming tutor.
Always explain concepts in a simple and clear way, using examples when possible.
If the user asks something unrelated to programming, politely bring the conversation back to programming topics.
"""

Trong ví dụ này, chúng ta đã:

• Định nghĩa vai trò của LLM (gia sư lập trình thân thiện)

• Mô tả hành vi mong muốn (giải thích đơn giản, kèm ví dụ)

• Đặt giới hạn về chủ đề được phép nói

2.2 Reasoning/Planning — Suy luận và lập kế hoạch

Một số kỹ thuật suy luận giúp agent có cách tiếp nhận thông tin, suy luận nội bộ và đưa ra quyết định có cấu trúc.

Chain-of-Thought (CoT) — Chuỗi suy nghĩ

CoT là kỹ thuật prompt engineering cho phép model suy luận qua các bước trung gian. Thay vì nhảy thẳng đến câu trả lời, model được yêu cầu giải thích từng bước trước khi đưa ra kết luận cuối cùng.

system_prompt = f"""
You are the assistant for a tiny candle shop.

Step 1: Check whether the user mentions either of our candles:
   • Forest Breeze (woodsy scent, 40 h burn, $18)
   • Vanilla Glow (warm vanilla, 35 h burn, $16)

Step 2: List any assumptions the user makes
   (e.g. "Vanilla Glow lasts 50 h" or "Forest Breeze is unscented").

Step 3: If an assumption is wrong, correct it politely.
   Then answer the question in a friendly tone.

Use exactly this output format:
Step 1: <your reasoning>
Step 2: <your reasoning>
Step 3: <your reasoning>
Response to user: <final answer>
"""

Tại sao CoT hiệu quả? Nó buộc model phải chia nhỏ vấn đề, không bỏ qua bước trung gian nào, giảm thiểu lỗi suy luận.

ReAct — Kết hợp suy luận và hành động

ReAct kết hợp reasoning (suy luận) và acting (hành động). Agent tiếp tục vòng lặp Thought → Action → Observation cho đến khi hoàn thành nhiệm vụ. Kỹ thuật này khắc phục điểm yếu của CoT (như hallucination) vì nó suy luận dựa trên thông tin thực tế thu được từ các hành động.

system_prompt = """You are an agent that can call two tools:

1. CurrencyAPI:
   • input: {base_currency, quote_currency}
   • returns: exchange rate (float)

2. Calculator:
   • input: {arithmetic_expression}
   • returns: result (float)

Follow strictly this response format:

Thought: <your reasoning>
Action: <ToolName>[<arguments>]
Observation: <tool result>
… (repeat as needed)
Answer: <final answer for the user>
"""

Luồng hoạt động:

1. Thought — Model suy nghĩ về những gì cần làm

2. Action — Gọi công cụ phù hợp

3. Observation — Nhận kết quả từ công cụ

4. Lặp lại cho đến khi có đủ thông tin để trả lời

Các kỹ thuật này hữu ích khi bạn cần tính minh bạch và khả năng kiểm soát đối với lý do agent đưa ra câu trả lời hoặc thực hiện hành động.

2.3 Memory — Bộ nhớ

LLM không có bộ nhớ tích hợp sẵn. “Memory” ở đây là nội dung bạn đưa vào prompt để cung cấp ngữ cảnh cho model. Có hai loại:

• Short-term memory (Bộ nhớ ngắn hạn): Ngữ cảnh trực tiếp mà model truy cập được trong cuộc hội thoại — tin nhắn gần nhất, N tin nhắn cuối, hoặc bản tóm tắt. Khi đạt giới hạn context window, các tin nhắn cũ sẽ bị loại bỏ.

• Long-term memory (Bộ nhớ dài hạn): Lưu trữ thông tin quan trọng vượt ngoài context window để sử dụng sau. Thường dùng vector database và kỹ thuật RAG để truy xuất khi cần.

# Quản lý short-term memory đơn giản
chat_history = []

# Tin nhắn thứ nhất
user_input = "I would like to buy 1 Forest Breeze. Can I pay $10?"
full_content = f"System instructions: {system_prompt}\n\n Chat History: {chat_history} \n\n User message: {user_input}"
response = client.models.generate_content(model="gemini-2.0-flash", contents=full_content)

# Thêm vào lịch sử
chat_history.append({"role": "user", "content": user_input})
chat_history.append({"role": "assistant", "content": response.text})

# Tin nhắn thứ hai — model nhớ được nội dung trước nhờ chat_history
user_input = "What did I say I wanted to buy?"
full_content = f"System instructions: {system_prompt}\n\n Chat History: {chat_history} \n\n User message: {user_input}"
response = client.models.generate_content(model="gemini-2.0-flash", contents=full_content)

Biến full_content bao gồm: system_prompt (hướng dẫn + kỹ thuật suy luận) + chat_history (bộ nhớ) + user_input (câu hỏi mới). Đây chính là cách kết hợp cả ba lớp của Orchestration.

3. Tools — Công cụ

Model rất giỏi xử lý thông tin, nhưng bị giới hạn bởi dữ liệu huấn luyện. Với công cụ, model có thể tương tác với hệ thống bên ngoài và truy cập kiến thức vượt ngoài dữ liệu huấn luyện.

3.1 Function Calling — Gọi hàm

Khi triển khai function calling, bạn kết nối model với các hàm. Bạn cung cấp tập hợp các hàm đã định nghĩa sẵn, và model tự quyết định khi nào sử dụng hàm nào và tham số nào cần thiết.

Quan trọng: Model không tự thực thi hàm. Nó chỉ cho biết hàm nào nên được gọi và truyền tham số dựa trên câu hỏi của user. Bạn cần viết code để thực thi hàm đó.

Quy trình tạo function call:

1. Định nghĩa hàm và mô tả hàm (tên, tham số, mục đích)

2. Gọi LLM kèm mô tả hàm

3. Thực thi hàm dựa trên output của model

4. Trả lời user

# Danh sách mua sắm
shopping_list: List[str] = []

# Định nghĩa hàm
def add_shopping_items(items: List[str]):
    """Add multiple items to the shopping list."""
    for item in items:
        shopping_list.append(item)
    return {"status": "ok", "added": items}

def list_shopping_items():
    """Return all items currently in the shopping list."""
    return {"shopping_list": shopping_list}

# Mô tả hàm (function declaration) — để model hiểu hàm làm gì
add_shopping_items_declaration = {
    "name": "add_shopping_items",
    "description": "Add one or more items to the shopping list",
    "parameters": {
        "type": "object",
        "properties": {
            "items": {
                "type": "array",
                "items": {"type": "string"},
                "description": "A list of shopping items to add"
            }
        },
        "required": ["items"]
    }
}

# Gửi đến model
response = client.models.generate_content(
    model="gemini-2.0-flash",
    contents=user_input,
    config=config,
)

# Model chọn hàm và trích xuất tham số
tool_call = response.candidates[0].content.parts[0].function_call
# -> name: "add_shopping_items", args: {"items": ["flour", "chocolate chips"]}

# Thực thi hàm dựa trên output của model
if tool_call.name == "add_shopping_items":
    result = add_shopping_items(**tool_call.args)

3.2 RAG — Retrieval Augmented Generation

RAG có nghĩa là:

• Retrieval — Khi user hỏi, hệ thống tìm kiếm nguồn bên ngoài để lấy thông tin liên quan

• Augmented — Thông tin được đưa vào prompt

• Generation — LLM tạo phản hồi dựa trên cả prompt gốc và ngữ cảnh bổ sung

Storing Pipeline

1. Load — Tải tài liệu

2. Split — Chia thành các đoạn nhỏ (chunks). Quan trọng vì giúp truy xuất chính xác hơn và LLM có giới hạn context window

3. Embed — Tạo vector số học cho mỗi chunk. Embedding cố gắng nắm bắt ý nghĩa — text có nội dung tương tự sẽ có vector tương tự

4. Store — Lưu vào vector database

Retrieving Pipeline

1. Embed query — Chuyển câu hỏi user thành vector

2. Retrieve — Tìm các chunks liên quan nhất bằng semantic similarity hoặc MMR

3. Combine — Ghép các chunks liên quan

4. Generate — Đưa vào LLM prompt để sinh câu trả lời

RAG quan trọng vì nó giảm hallucination và cho phép LLM trả lời về các domain cụ thể hoặc dữ liệu riêng tư mà không cần huấn luyện lại model.

Nâng cao hiệu suất Model

Có ba chiến lược chính:

1. In-context Learning — Học trong ngữ cảnh

“Dạy” model cách thực hiện tác vụ bằng cách đưa ví dụ trực tiếp trong prompt, không thay đổi trọng số của model.

Các loại in-context learning:

• Zero-shot: Không có ví dụ, chỉ có hướng dẫn

• One-shot: Một ví dụ minh họa

• Few-shot: Vài ví dụ minh họa

• CoT: Hướng dẫn suy luận từng bước

• ReAct: Kết hợp suy luận và hành động

Ví dụ One-shot:

system_prompt = f"""You are a helpful assistant that extracts action items.

Example 1
Transcript:
'John will draft the budget by Friday. Sarah volunteers to review the marketing deck next week.'

Actions:
- John: Draft budget (due Friday)
- Sarah: Review marketing deck (next week)

Now you
Transcript: {user_query}

Actions:
"""

2. Retrieval-based In-context Learning — Học dựa trên truy xuất

Model truy xuất ngữ cảnh bên ngoài (như tài liệu) và thêm nội dung liên quan vào prompt khi suy luận. Đây chính là RAG đã nói ở trên.

3. Fine-tuning — Tinh chỉnh

Huấn luyện thêm model trên tập dữ liệu cụ thể để model “nội hóa” hành vi hoặc kiến thức mới. Trọng số của model được cập nhật.

Ví dụ để so sánh ba chiến lược

Hãy tưởng tượng bạn đang đào tạo một hướng dẫn viên du lịch ở Đà Nẵng:

• In-Context Learning: Bạn đưa cho hướng dẫn viên vài tờ ghi chú với ví dụ: “Nếu ai hỏi về cầu Rồng, nói thế này. Nếu hỏi về đồ ăn, nói thế kia.” Anh ta không hiểu sâu về thành phố, nhưng có thể làm theo ví dụ của bạn.

• Retrieval-Based Learning (RAG): Bạn trang bị cho hướng dẫn viên điện thoại + bản đồ + Google search. Anh ta không cần nhớ hết nhưng biết cách tra cứu thông tin ngay lập tức khi được hỏi.

• Fine-Tuning: Bạn cho hướng dẫn viên đào tạo chuyên sâu nhiều tháng tại thành phố. Kiến thức đã nằm sẵn trong đầu khi bắt đầu dẫn tour.

LangChain là gì và vào cuộc ở đâu?

LangChain là framework được thiết kế để đơn giản hóa việc phát triển ứng dụng dựa trên LLM.

Hệ sinh thái LangChain bao gồm:

• LangChain — Framework cơ bản, cho phép chuyển đổi giữa các provider (Gemini, GPT...) mà không cần thay đổi code

• LangGraph — Xây dựng, triển khai và quản lý workflow agent

• LangSmith — Debug, test và giám sát ứng dụng LLM

Ngoài LangChain, bạn cũng có thể xem xét OpenAI Agents SDK hoặc Google Agent Development Kit (ADK).

Xây dựng Agent với LangChain

So với function calling thủ công, LangChain đơn giản hóa đáng kể:

# Không cần viết function declaration thủ công nữa
# Decorator @tool tự động chuyển hàm thành mô tả có cấu trúc

@tool
def add_shopping_items(items: List[str]):
    """Add multiple items to the shopping list."""
    for item in items:
        shopping_list.append(item)
    return {"status": "ok", "added": items}

@tool
def list_shopping_items():
    """Return all items currently in the shopping list."""
    return {"shopping_list": shopping_list}

# Cấu hình
llm = ChatGoogleGenerativeAI(model="gemini-2.0-flash", temperature=0)
tools = [add_shopping_items, list_shopping_items]

# ChatPromptTemplate tổ chức thông tin trong prompt
# agent_scratchpad = bộ nhớ làm việc của agent (lịch sử suy nghĩ, tool calls, kết quả)
prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a helpful assistant that manages shopping lists."),
    ("human", "{input}"),
    MessagesPlaceholder(variable_name="agent_scratchpad")
])

# Tạo agent — tự động xử lý logic gọi hàm
agent = create_openai_tools_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

# Chạy
response = agent_executor.invoke({"input": user_input})

Khác biệt chính so với cách thủ công:

• Không cần viết function declaration

• Không cần if/elif để xác định hàm nào cần gọi

• AgentExecutor tự điều phối toàn bộ: agent suy luận → chọn tool → executor thực thi → trả kết quả

Khi nào nên xây dựng Agent?

Xây dựng agent không phải lúc nào cũng là giải pháp hiệu quả nhất. Một giải pháp deterministic (tất định — theo quy tắc rõ ràng, không có “hộp đen”) có thể đủ tốt.

Cả OpenAI và Anthropic đều khuyến nghị: bắt đầu từ giải pháp đơn giản nhất, chỉ tăng độ phức tạp khi cần thiết.

Hãy cân nhắc xây dựng agent khi:

• Quyết định phức tạp — Quy trình đòi hỏi đánh giá tinh tế, xử lý ngoại lệ, hoặc quyết định phụ thuộc nhiều vào ngữ cảnh (ví dụ: xác định khách hàng có đủ điều kiện hoàn tiền không)

• Quy tắc khó bảo trì — Workflow dựa trên bộ quy tắc phức tạp, khó cập nhật, và thay đổi liên tục

• Dữ liệu phi cấu trúc — Tác vụ cần hiểu ngôn ngữ tự nhiên, trích xuất thông tin từ PDF, email, hình ảnh, trang web...

Tóm lại

Agent là hệ thống được thiết kế để hoàn thành nhiệm vụ thay con người một cách độc lập. Chúng bao gồm ba thành phần: hướng dẫn (instructions), mô hình (model), và công cụ (tools). Có nhiều cách nâng cao hiệu suất model: cải thiện prompt với ví dụ, dùng RAG để bổ sung ngữ cảnh, hoặc fine-tuning. LangChain giúp đơn giản hóa code, nhưng bạn nên hiểu những gì abstraction đang làm bên dưới. Luôn nhớ rằng đơn giản là cách tốt nhất để xây dựng hệ thống agentic.

Nếu bạn mới tiếp xúc với nội dung này, hãy tiêu hóa hết kiến thức trước, đọc lại vài lần, và đọc thêm các bài viết gốc để có nền tảng vững chắc. Sau đó, hãy bắt tay vào xây dựng thứ gì đó — một ứng dụng đơn giản — để tạo cầu nối giữa lý thuyết và thực hành. Bắt đầu build là cách tốt nhất để học.

Tham khảo các bài viết sau

• Building effective agents — Anthropic

• Agents — Google

• A practical guide to building agents — OpenAI

• Chain of Thought Prompting Elicits Reasoning in Large Language Models — Google Research

• ReAct: Synergizing Reasoning and Acting in Language Models — Google Research

• Small Language Models: A Guide With Examples — DataCamp

Anh Tùng: Chào Duthaho. Anh thấy CV của em có kinh nghiệm sâu về System Design. Hôm nay chúng ta sẽ giải bài toán thiết kế tính năng “On This Day” của Facebook. Em hãy hình dung hệ thống phải phục vụ lượng user khổng lồ. Em bắt đầu đi.

Duthaho: Chào anh Tùng. Bài toán rất thú vị. Trước khi đi vào kiến trúc, em muốn làm rõ một số requirements để khoanh vùng phạm vi:

1. Scale: Chúng ta đang nói về quy mô cỡ Facebook, tức là khoảng 2-3 tỷ users?

2. Tính năng: Chỉ hiển thị bài viết (Posts), ảnh (Photos) hay cả quan hệ bạn bè (Friends)?

3. Latency: Yêu cầu độ trễ thế nào khi user load feed này?

Anh Tùng: Tốt. Giả sử 2 tỷ user active. Tập trung vào Posts và Photos. Độ trễ phải cực thấp, dưới 200ms user phải thấy nội dung. Và quan trọng nhất: Hệ thống này không được làm sập Core Feed chính.

Duthaho: Các hướng tiếp cận & trade-offs:

Cách 1: Query trực tiếp (Real-time)

Khi user login, thực hiện câu query SQL kiểu: SELECT * FROM posts WHERE user_id = X AND MONTH(created_at) = M AND DAY(created_at) = D

• Ưu điểm: Dữ liệu luôn tươi mới (real-time). Không tốn storage lưu cache.

• Nhược điểm:

  • Hiệu năng thảm họa: Với bảng posts chứa hàng nghìn tỷ bản ghi, việc query không theo index cluster (thường là Time-series tăng dần) mà query theo “ngày/tháng” bỏ qua “năm” là cực nặng.

  • DB Load: 2 tỷ queries phức tạp mỗi sáng sẽ đánh sập bất kỳ database nào.

Cách 2: Pre-computation (Batch Processing - Offline)

Chạy một job hàng ngày quét qua dữ liệu, tính toán trước kết quả cho tất cả user và lưu vào một bảng riêng hoặc Cache.

• Ưu điểm: Read cực nhanh (O(1)). Không ảnh hưởng DB chính vào giờ cao điểm.

• Nhược điểm:

  • Lãng phí tài nguyên: Rất nhiều user không online ngày hôm đó nhưng vẫn tốn công tính toán và lưu trữ.

  • Stale Data: Nếu user vừa xóa bài viết 5 phút trước, job chạy từ đêm qua vẫn hiện bài đó -> Trải nghiệm tệ (và rủi ro privacy).

Cách 3: Hybrid (Lazy Loading + Caching)

Không tính trước cho tất cả. Chỉ khi user có dấu hiệu active (login) hoặc gần đến giờ gửi noti, hệ thống mới tính toán và cache lại với TTL (Time To Live) là 24h.

Với yêu cầu không ảnh hưởng Core Feed và latency thấp, em sẽ loại bỏ ngay phương án query trực tiếp (Real-time Query) vào bảng Posts chính. Query kiểu WHERE user_id = ? AND MONTH(date) = ? trên bảng hàng tỷ dòng là thảm họa về hiệu năng.

Em đề xuất kiến trúc Hybrid với việc tính toán trước (Pre-computation):

• Memory Service: Microservice chịu trách nhiệm logic nghiệp vụ “Ngày này năm xưa”.

• Activity Log DB (Source of Truth): Database chứa tất cả activities (Posts, Likes, Photos).

• Search Index / Secondary Index: Hệ thống đánh index đặc biệt để query theo (User_ID, Month, Day).

• Cache Layer (Redis/Memcached): Lưu kết quả đã tính toán (”Memories Feed”) của user trong ngày.

• Notification Service: Quản lý việc đẩy thông báo.

Anh Tùng: Hợp lý. Vậy em sẽ lưu trữ dữ liệu “lookup” này như thế nào để query nhanh nhất?

Duthaho: Vấn đề khó nhất ở đây là: Làm sao query nhanh dữ liệu cũ?

Dữ liệu Facebook thường lưu theo Time-series (Append only). Dữ liệu mới nằm trên RAM/Hot storage, dữ liệu cũ (Cold data) nằm ở đĩa cứng chậm hơn. Query random access vào dữ liệu 5 năm trước là rất tốn kém (Disk I/O).

Giải pháp: Thay vì scan bảng posts, ta cần một bảng Index riêng (Lookup table):

• Key: User_ID

• Columns: List các Post_ID kèm Timestamp.

• Tuy nhiên, cái này vẫn chưa tối ưu cho query “Ngày này”.

• Ta cần một cấu trúc index dạng: Bucket_Map<User_ID, List<Post_Metadata>>.

• Facebook thực tế sử dụng hệ thống graph database của họ (TAO) và lớp caching cực mạnh. Nhưng với thiết kế tổng quát, ta có thể dùng Cassandra hoặc HBase với RowKey: UserID#Month#Day.

  • Khi query UserID=123, Month=12, Day=06, ta lấy được ngay lập tức tất cả post ID của các năm.

Quy trình lọc (Filtering Pipeline):

1. Fetch: Lấy list Post IDs.

2. Hydrate: Gọi sang Post Service để lấy nội dung chi tiết.

3. Privacy Check (Quan trọng): Kiểm tra ACL hiện tại. (User A post lên tường User B 5 năm trước, nay A block B -> B không được thấy).

4. Rank: Dùng ML model nhẹ để chọn ra post nhiều like/comment nhất để hiển thị đầu tiên.

Nếu dùng MySQL, em sẽ tạo một bảng riêng là memories_lookup.

Schema sẽ trông như thế này:

CREATE TABLE memories_lookup (
    user_id BIGINT,
    mm_dd SMALLINT, -- Ví dụ: 1206 (Ngày 6 tháng 12)
    post_id BIGINT,
    post_year SMALLINT,
    PRIMARY KEY (user_id, mm_dd, post_id)
);

Em chọn Primary Key là (user_id, mm_dd, post_id) vì nó là Clustered Index.

Khi query SELECT * FROM memories_lookup WHERE user_id = X AND mm_dd = 1206, dữ liệu nằm liền nhau vật lý trên đĩa cứng. Ổ cứng chỉ cần seek 1 lần và đọc tuần tự (Sequential Read). Tốc độ sẽ cực nhanh.

Anh Tùng: Tại sao em không dùng Index trên bảng Posts có sẵn mà phải đẻ thêm bảng này? Tốn storage lắm.

Duthaho: Vì bảng Posts thường được tối ưu cho Time-series (mới nhất hiện trước). Index thường là (user_id, created_at).

Nếu em query tìm ngày 06/12 trên bảng đó, DB engine phải scan qua toàn bộ lịch sử của user, nhảy cóc qua các năm, tạo ra Random I/O rất lớn.

Việc tách bảng lookup giúp cô lập tải đọc (Read Load) khỏi bảng chính. Storage rẻ hơn Compute I/O nhiều, nên đây là trade-off đáng giá.

Anh Tùng: OK, đồng ý về Schema. Giờ sang vấn đề vận hành.

8:00 sáng, hệ thống bắn Notification cho 500 triệu người dùng. 50 triệu người cũng lúc bấm vào xem. Database của em chịu nổi không?

Duthaho: Để giải quyết vấn đề này, chúng ta cần chiến lược khác nhau:

1. Kỹ thuật “Jitter” (Phân tán ngẫu nhiên): Đừng bao giờ gửi 100 triệu thông báo vào đúng 08:00:00.

• Thiết kế: Notification Service sẽ chia user thành các lô (batches).

• Thực thi: Gửi rải rác trong khung giờ từ 08:00 đến 09:00. Ví dụ: User A nhận lúc 8:05, User B nhận lúc 8:42.

• Hiệu quả: Giảm tải đỉnh (peak load) xuống 60 lần (nếu rải đều trong 60 phút).

2. Cache Warming (Làm nóng Cache):

• Logic: Khi hệ thống chạy job ban đêm để tìm ra “Ai có kỷ niệm hôm nay” để đưa vào danh sách gửi Notification, hệ thống đã có dữ liệu trong tay.

• Hành động: Ngay lúc tính toán xong (ví dụ 4:00 AM), hãy đẩy luôn dữ liệu đó vào Redis với TTL là 24h.

• Kết quả: Khi User bấm vào thông báo lúc 8:00 AM, request đi thẳng vào Redis lấy dữ liệu ra. Database gần như không chịu tải gì cả (Zero DB Hit cho luồng này).

3. Circuit Breaker & Fallback: Giả sử Redis chết hoặc quá tải?

• Đừng để request chọc thẳng xuống Database (sẽ làm sập luôn DB).

• Kích hoạt Circuit Breaker: Trả về một thông báo nhẹ nhàng “Hệ thống đang bận, hãy quay lại sau” hoặc hiển thị một phiên bản cached cũ hơn, thay vì để user chờ đợi gây tắc nghẽn thêm.

Anh Tùng: Khá lắm. Cache Warming là key ở đây.

Anh Tùng: Giờ anh làm khó em một chút.

Em lưu dữ liệu vào bảng memories_lookup lúc 3:00 sáng.

Lúc 7:00 sáng, User A xóa bài viết gốc ở bảng Posts.

Lúc 8:00 sáng, User A vào xem “On This Day”.

Làm sao em đảm bảo bài viết đó biến mất? Đồng bộ dữ liệu kiểu gì?

Duthaho: Em có 2 lựa chọn: Dual Write (Ghi đồng bộ) hoặc CDC (Bất đồng bộ).

Em từ chối Dual Write (tức là code App vừa xóa Post vừa xóa Lookup trong 1 transaction) vì nó làm chậm thao tác xóa của user và ghép chặt 2 hệ thống (Tight Coupling).

Em chọn CDC (Change Data Capture) kết hợp với chiến lược Check-on-Read:

1. Async deletion: Khi Post bị xóa, DB bắn log update vào Kafka. Một Worker sẽ đọc Kafka để xóa dòng tương ứng trong memories_lookup. Sẽ có độ trễ vài giây.

2. Safety Net (Lưới bảo vệ): Đây là mấu chốt.

   • Khi User A load “On This Day”, em lấy được list Post_ID từ lookup (có thể vẫn còn sót bài đã xóa).

   • Nhưng trước khi trả về cho Client, em sẽ có bước Hydration (lấy chi tiết nội dung). Em gọi sang Post Service với list ID đó.

   • Post Service check DB chính, thấy bài đã xóa -> Trả về null.

   • Service “On This Day” thấy null thì filter bỏ đi.

User sẽ không bao giờ thấy “Ghost Data” (dữ liệu ma), dù hệ thống lookup có chưa kịp cập nhật.

Anh Tùng: Cách giải quyết “Check-on-Read” rất thông minh. Nó đảm bảo Consistency mà không hy sinh Availability của luồng Write.

Câu hỏi cuối: Em ước tính hệ thống này cần bao nhiêu Storage cho 2 tỷ user?

Duthaho:

• 2 tỷ user. Trung bình 500 posts/user -> 1,000 tỷ bản ghi (records).

• Mỗi record lookup (User 8B + Date 2B + PostID 8B + Year 2B + Overhead) ~ 30-40 Bytes.

• Tổng raw data = 1,000 tỷ * 40 Bytes = 40 TB.

• Với Replication Factor = 3 (để an toàn) -> 120 TB.

• Con số này hoàn toàn khả thi để lưu trữ trên cụm Cassandra hoặc HBase, thậm chí Sharded MySQL (khoảng 60-100 instances).

Anh Tùng: Cảm ơn Duthaho. Anh rất ấn tượng về cách em đi từ Schema chi tiết lên đến Architecture tổng thể và xử lý các Edge cases. Em có tư duy của một SA thực thụ.

Bối cảnh:

• Người phỏng vấn: Anh Khoa (Solution Architect cấp cao)

• Ứng viên: duthaho

• Vai trò: Kỹ sư Backend/Database cấp cao

• Mục tiêu: Đánh giá kiến thức chuyên sâu về kiến trúc bên trong của MySQL InnoDB.

Anh Khoa: Chào duthaho, anh là Khoa. Cảm ơn em đã tham gia buổi phỏng vấn hôm nay. Anh xem qua CV thì thấy em có nhiều kinh nghiệm làm việc với MySQL. Hôm nay chúng ta sẽ trao đổi sâu một chút về kiến trúc của InnoDB nhé. Em sẵn sàng chứ?

duthaho: Dạ, em sẵn sàng. Chào anh Khoa.

Anh Khoa: OK, bắt đầu nhé. Câu hỏi đầu tiên, theo em, thành phần nào là quan trọng nhất quyết định hiệu năng của InnoDB và tại sao?

duthaho: Dạ, theo em đó là InnoDB Buffer Pool. Lý do là vì nó là một vùng nhớ cache lớn trong RAM, dùng để lưu trữ các trang (pages) dữ liệu và chỉ mục (index) được truy cập thường xuyên. Việc này giúp giảm thiểu tối đa các thao tác I/O đọc/ghi xuống đĩa, vốn là nút thắt cổ chai lớn nhất của database. Hầu hết các thao tác đọc sẽ được phục vụ trực tiếp từ RAM, nhanh hơn hàng nghìn lần so với đọc từ SSD.

Anh Khoa: Rất tốt. Vậy khi một câu lệnh UPDATE chạy, nó sẽ làm thay đổi một trang trong Buffer Pool. Trang đó được gọi là gì, và nó khác gì với một trang “sạch” (clean page)?

duthaho: Dạ, khi một trang bị thay đổi trong bộ nhớ, nó được đánh dấu là “dirty page” (trang bẩn).

• Dirty Page: Là trang trong RAM có nội dung mới hơn (khác) so với nội dung trên đĩa.

• Clean Page: Là trang trong RAM có nội dung giống hệt với nội dung trên đĩa.

  Sự khác biệt này rất quan trọng, vì InnoDB có thể loại bỏ (evict) một clean page bất cứ lúc nào để lấy chỗ trống, nhưng phải ghi (flush) một dirty page xuống đĩa trước khi loại bỏ nó.

Anh Khoa: Chính xác. Giờ hãy nói về việc tối ưu ghi. Giả sử em INSERT một bản ghi mới vào một bảng có 5 secondary index (chỉ mục phụ). Nếu không có cơ chế đặc biệt, việc này sẽ rất tốn kém I/O. InnoDB sử dụng cái gì để giải quyết vấn đề này?

duthaho: Dạ, đó chính là vai trò của Change Buffer. Thay vì ngay lập tức đọc các trang của 5 chỉ mục phụ đó từ đĩa vào Buffer Pool chỉ để thêm một bản ghi mới (gây ra 5 thao tác đọc ngẫu nhiên), InnoDB sẽ “ghi chú” lại sự thay đổi này vào một vùng đặc biệt trong Buffer Pool. Thao tác INSERT được trả về “thành công” ngay lập tức. Các thay đổi này sẽ được “trộn” (merge) vào các trang chỉ mục thực sự sau đó, thường là bởi một luồng nền hoặc khi trang đó được đọc vì một lý do khác.

Anh Khoa: Một điểm rất quan trọng: Tại sao Change Buffer lại chỉ hoạt động hiệu quả với non-unique secondary index? Điều gì xảy ra nếu chỉ mục đó là UNIQUE?

duthaho: Dạ, vì với một chỉ mục UNIQUE, khi INSERT hoặc UPDATE, InnoDB bắt buộc phải kiểm tra xem giá trị đó đã tồn tại hay chưa để đảm bảo tính duy nhất. Để làm việc này, nó buộc phải đọc trang chỉ mục liên quan từ đĩa vào. Vì đằng nào cũng phải đọc từ đĩa, nên việc dùng Change Buffer không còn ý nghĩa tối ưu nữa. Còn với non-unique index, nó có thể “ghi mù” (blind write) mà không cần kiểm tra, nên Change Buffer phát huy tối đa tác dụng.

Anh Khoa: Rất rõ ràng. OK, vậy bây giờ Buffer Pool của chúng ta chứa rất nhiều “dirty pages”. Làm thế nào InnoDB đưa các trang này xuống đĩa một cách an toàn mà không làm “đứng” toàn bộ hệ thống?

duthaho: InnoDB sử dụng một cơ chế gọi là “Fuzzy Checkpointing” (Checkpointing mờ). Đây là một tiến trình chạy nền, liên tục và từ từ. Các luồng Page Cleaner sẽ quét Buffer Pool và “xả” (flush) một lượng nhỏ các dirty pages cũ nhất xuống đĩa theo thời gian. Nó được gọi là “fuzzy” vì nó không dừng toàn bộ hoạt động của CSDL lại. Nó đối lập hoàn toàn với “Sharp Checkpoint” – một cơ chế sẽ dừng mọi thứ, xả tất cả dirty pages xuống đĩa cùng lúc, gây ra một cơn bão I/O và làm hệ thống bị “khựng” lại.

Anh Khoa: Đây là một câu hỏi tình huống. Giả sử em có Buffer Pool 10GB, đang chứa 8GB dữ liệu “nóng” (hot data) của người dùng. Một lập trình viên lỡ chạy một câu lệnh SELECT COUNT(*) trên một bảng log rất lớn (ví dụ 20GB). Về lý thuyết, việc này sẽ đọc 20GB dữ liệu vào cache và “đá văng” (evict) toàn bộ 8GB dữ liệu nóng kia. Tình huống này gọi là gì và InnoDB ngăn chặn nó như thế nào?

duthaho: Dạ, tình huống đó gọi là “cache pollution” (ô nhiễm cache). InnoDB giải quyết vấn đề này rất thông minh. Nó không dùng một danh sách LRU (Least Recently Used) đơn giản, mà dùng một “midpoint insertion strategy”.

1. Danh sách LRU được chia làm 2 phần: “young” (khoảng 63%, chứa dữ liệu nóng) và “old” (khoảng 37%, chứa dữ liệu mới vào).

2. Khi một trang được đọc từ đĩa lần đầu (như trong lúc quét bảng), nó được chèn vào đầu của danh sách “old” (tức là “midpoint”).

3. Khi quá trình quét bảng diễn ra, các trang này sẽ bị đẩy dần xuống đuôi danh sách “old” và bị loại bỏ (evict) từ đó. Chúng không bao giờ được “thăng hạng” lên danh sách “young” chỉ với một lần truy cập.

4. Chỉ khi một trang trong danh sách “old” được truy cập lại sau một khoảng thời gian (mặc định là 1 giây), nó mới được coi là “nóng” và được thăng hạng lên danh sách “young”.

   Kết quả là, toàn bộ bảng log 20GB đó sẽ đi qua vùng “old” và bị thải ra mà không hề ảnh hưởng đến 8GB dữ liệu nóng trong vùng “young”.

Anh Khoa: Tuyệt vời, rất chi tiết. Câu hỏi cuối cùng. Với tư cách là người vận hành hệ thống, em sẽ dùng câu lệnh nào và nhìn vào các chỉ số (metrics) quan trọng nào để đánh giá sức khỏe của Buffer Pool?

duthaho: Dạ, em sẽ dùng câu lệnh SHOW ENGINE INNODB STATUS;. Trong đó, em sẽ quan tâm nhất đến:

1. Buffer pool hit rate: Nằm trong phần BUFFER POOL AND MEMORY. Tỷ lệ này phải luôn ở mức rất cao, lý tưởng là > 990 / 1000 (tức 99.9%). Nếu nó thấp, có nghĩa là Buffer Pool quá nhỏ.

2. Modified db pages (Dirty Pages): Cũng trong phần đó. Nếu con số này quá cao và liên tục tăng, nó cho thấy hệ thống I/O (đĩa) đang không “xả” kịp lượng ghi (write) của hệ thống.

3. ---LOG--- section: Em sẽ xem Log sequence number và Last checkpoint at. Khoảng cách giữa hai số này (Checkpoint Age) cho biết redo log đang được sử dụng nhiều đến đâu. Nếu khoảng cách này gần bằng tổng kích thước redo log, hệ thống sắp bị “nghẽn” vì checkpointing phải hoạt động hết công suất.

Anh Khoa: OK, duthaho. Phần của anh hôm nay là vậy. Rất cảm ơn em về phần trao đổi rất sâu. Em có câu hỏi nào cho anh không?

duthaho: Dạ, hiện tại em chưa có. Em cảm ơn anh Khoa đã dành thời gian ạ.

Anh Khoa: Cảm ơn em. Bộ phận HR sẽ liên hệ với em về các bước tiếp theo nhé. Chào em.

Bối cảnh: duthaho đang phỏng vấn cho vị trí Senior Backend Developer tại một công ty công nghệ lớn. Người phỏng vấn là Anh Khoa, một Solution Architect.

BẮT ĐẦU BUỔI PHỎNG VẤN

Anh Khoa: Chào duthaho, tôi là Khoa. Cảm ơn bạn đã dành thời gian tham gia buổi phỏng vấn hôm nay. Trong CV bạn có ghi kinh nghiệm làm việc sâu với MySQL, tôi rất muốn đào sâu về phần này. Chúng ta bắt đầu luôn nhé?

duthaho: Vâng, chào anh Khoa. Tôi đã sẵn sàng.

Anh Khoa: Tốt. Câu đầu tiên nhé. Khi nói về InnoDB, chúng ta hay nhắc đến “page”. Bạn có thể giải thích “page” là gì và tại sao kích thước mặc định của nó lại là 16KB không?

duthaho: Dạ vâng. Page (hay còn gọi là block) là đơn vị I/O nhỏ nhất mà InnoDB dùng để đọc và ghi dữ liệu xuống đĩa. Thay vì đọc từng row, InnoDB sẽ đọc/ghi nguyên một page 16KB vào Buffer Pool.

Việc chọn 16KB là một sự cân bằng có tính toán:

1. Hiệu suất I/O: Nó đủ lớn để gom nhiều block 4KB của hệ điều hành/ổ đĩa, giúp giảm số lần I/O vật lý, đặc biệt quan trọng với HDD.

2. Cấu trúc B+Tree: Kích thước 16KB cho phép mỗi node (page) chứa được nhiều key và con trỏ, làm cho cây B+Tree “rộng” và “nông” hơn. Điều này giúp giảm số lần đọc page cần thiết để đi từ root đến leaf, tăng tốc độ truy vấn.

3. Amortization (Chia đều chi phí): Mỗi page đều có header và trailer (chứa metadata, checksum...). Với page 16KB, phần overhead này chiếm tỷ lệ nhỏ, tối ưu không gian cho dữ liệu.

Anh Khoa: Giải thích rất rõ ràng. Giờ hãy đi sâu hơn. Giả sử tôi có một page đã đầy 100% và tôi INSERT một row mới thuộc về page đó. Chuyện gì sẽ xảy ra?

duthaho: Đó là lúc xảy ra “page split”.

Anh Khoa: Bạn nói rõ hơn được không? “Page split” ảnh hưởng thế nào đến hiệu năng? Tôi không chỉ muốn biết về độ trễ của query đó, mà là ảnh hưởng lâu dài đến toàn hệ thống.

duthaho: Vâng. Khi một page (ví dụ Page 100) bị đầy:

1. InnoDB sẽ “khóa” (latch) page đó lại.

2. Nó tạo một page mới (Page 101).

3. Nó di chuyển khoảng một nửa số row từ Page 100 sang Page 101.

4. Nó cập nhật lại các con trỏ ở page cha (non-leaf) để trỏ đến cả hai page này, và cập nhật linked-list ở mức leaf.

Ảnh hưởng hiệu năng là rất rõ:

1. Tức thì: Query INSERT (hoặc UPDATE) gây ra split sẽ bị trễ (latency spike) vì nó phải làm rất nhiều việc (cấp phát page, di chuyển dữ liệu, ghi log...) thay vì chỉ ghi vào bộ nhớ.

2. Lâu dài (Đây là vấn đề lớn): Nó gây ra fragmentation (phân mảnh). Hai page cũ và mới giờ chỉ còn đầy khoảng 50%. Điều này làm lãng phí không gian đĩa và quan trọng hơn là lãng phí Buffer Pool. Hệ thống sẽ phải đọc nhiều page hơn để lấy cùng một lượng dữ liệu, làm giảm hiệu quả của cache.

Anh Khoa: Rất tốt. Bạn có nhắc đến “fragmentation”. Vậy tình huống thực tế nào thường gây ra fragmentation nhiều nhất?

duthaho: Nguyên nhân phổ biến nhất là sử dụng Primary Key không tuần tự, ví dụ như UUID (v4). Các INSERT sẽ đi vào các page ngẫu nhiên trong B-Tree, khiến các page này liên tục bị split và để lại 50% trống. Ngược lại, AUTO_INCREMENT thì luôn ghi vào page cuối cùng (append-only), rất hiệu quả và gần như không gây fragmentation.

Anh Khoa: Chính xác. Giờ hãy nói về schema. Tôi có một bảng articles với cột content kiểu TEXT. Khi tôi SELECT id, title FROM articles WHERE id = 123;, InnoDB có đọc dữ liệu của cột content không?

duthaho: Dạ không. Đây là một cơ chế tối ưu quan trọng. Với các kiểu dữ liệu LOB (Large Object) như TEXT hay BLOB, InnoDB sẽ lưu trữ chúng “off-page”.

Anh Khoa: “Off-page”? Tức là sao?

duthaho: Tức là trên page lá (leaf page) của B-Tree (nơi chứa dữ liệu row), thay vì lưu toàn bộ 5MB TEXT, InnoDB chỉ lưu một con trỏ 20-byte. Con trỏ này sẽ trỏ đến một chuỗi các page đặc biệt khác chuyên dùng để lưu dữ liệu BLOB.

Vì vậy, khi anh SELECT id, title, InnoDB chỉ cần đọc leaf page chính, lấy id và title. Nó hoàn toàn không cần đọc các page off-page kia, giúp truy vấn cực kỳ nhanh và không làm ô nhiễm Buffer Pool với dữ liệu LOB khổng lồ.

Anh Khoa: Vậy anti-pattern ở đây là gì?

duthaho: Rõ ràng là SELECT * FROM articles;. Câu lệnh này buộc InnoDB phải đi theo từng con trỏ 20-byte của mỗi row để đọc toàn bộ dữ liệu TEXT off-page, kể cả khi ứng dụng không cần. Điều này giết chết hiệu suất I/O và đẩy toàn bộ index/data page nóng ra khỏi Buffer Pool.

Anh Khoa: OK. Vậy giữa VARCHAR(20000) và TEXT, cái nào tốt hơn?

duthaho: Nó tùy vào mục đích. TEXT được thiết kế để lưu off-page (với con trỏ 20-byte). VARCHAR thì cố gắng lưu inline (trên page chính). Tuy nhiên, VARCHAR(20000) nếu chứa dữ liệu lớn cũng sẽ bị đẩy ra off-page, hoạt động tương tự TEXT.

Nhưng có một cái bẫy với VARCHAR lớn: Nếu MySQL cần tạo bảng tạm trong bộ nhớ (ví dụ khi GROUP BY), nó có thể cấp phát bộ nhớ dựa trên kích thước tối đa (20000), gây lãng phí RAM. Vì vậy, nếu dữ liệu chắc chắn lớn, tôi có xu hướng dùng TEXT để rõ ràng về mặt kiến trúc là nó sẽ được lưu off-page.

Anh Khoa: Chúng ta đã nói nhiều về leaf page. Vậy “leaf page” và “non-leaf page” trong B-Tree khác nhau điểm nào?

duthaho: “Non-leaf page” (page không phải lá) là các “biển chỉ dẫn”. Chúng chỉ chứa (Key, Con trỏ) để điều hướng. Ví dụ: “Các key < 100 thì đi page 201”, “Các key 100-200 thì đi page 202”. Page trên cùng là Root.

Còn “Leaf page” là “đích đến”. Chúng nằm ở tầng dưới cùng, chứa dữ liệu thực tế (với Clustered Index) hoặc chứa (Key, Primary Key) (với Secondary Index). Và điểm khác biệt quan trọng nhất: Tất cả các leaf page được liên kết với nhau bằng một doubly-linked list.

Anh Khoa: Tại sao cái linked-list đó lại quan trọng?

duthaho: Nó cực kỳ quan trọng cho range scan. Khi anh chạy SELECT * FROM users WHERE id > 100 AND id < 150, MySQL sẽ duyệt B-Tree 1 lần để tìm id = 100 (ở Leaf Page X). Sau đó, thay vì duyệt lại cây, nó chỉ cần đi theo con trỏ NEXT_PAGE của linked-list (từ Page X sang Page Y,...) để scan lấy dữ liệu một cách tuần tự và hiệu quả.

Anh Khoa: Rất tốt. Câu cuối cùng. Bạn đã nhắc đến “Buffer Pool”. Vậy “dirty page” là gì, và nó liên quan gì đến việc UPDATE của tôi được trả về “OK” gần như ngay lập tức?

duthaho: Dạ. “Buffer Pool” là cache trong RAM chứa các page 16KB.

• Clean Page: Là page trong Buffer Pool giống hệt page trên đĩa.

• Dirty Page: Là page trong Buffer Pool đã bị thay đổi (ví dụ do UPDATE) nhưng chưa được ghi xuống đĩa.

Khi anh UPDATE một row, InnoDB thực hiện 2 việc song song:

1. Nó tìm page đó trong Buffer Pool, thay đổi dữ liệu trong RAM, và đánh dấu page đó là “dirty”.

2. Nó ghi lại sự thay đổi này vào Redo Log (WAL) và “fsync” file log đó xuống đĩa.

Bởi vì việc ghi vào Redo Log (ghi tuần tự) rất nhanh, và việc thay đổi trong RAM (Buffer Pool) cũng tức thời, nên InnoDB có thể trả về “OK” cho anh ngay. Công việc nặng nhọc là “flush” (ghi) cái dirty page 16KB kia (ghi ngẫu nhiên) xuống file dữ liệu .ibd sẽ được một thread nền xử lý sau một cách từ từ. Đây là cơ chế giúp InnoDB có write performance cao.

Anh Khoa: Cảm ơn duthaho. Bạn hiểu rất sâu về các thành phần cốt lõi. Tôi không có câu hỏi nào thêm. Bạn có câu hỏi gì cho tôi không?

duthaho: Dạ, anh có thể chia sẻ thêm về...

KẾT THÚC BUỔI PHỎNG VẤN

Chào mọi người, lại là duthaho đi phỏng vấn đây. Hôm nay chúng ta cùng đào sâu tìm hiểu về bài toán thực tế rất hay gặp: Bulk Download. Mọi người nhớ ủng hộ mình bằng cách like và subscribe nhé!

Bối cảnh buổi phỏng vấn

• Người phỏng vấn: Anh Khoa (Senior Solution Architect)

• Ứng viên: duthaho

• Vị trí: Senior Backend Engineer / Junior Solution Architect

• Thời lượng: 30 phút

• Chủ đề: System Design - Tính năng Download file hàng loạt

Bắt đầu buổi phỏng vấn

(Anh Khoa): Chào duthaho, tôi là Khoa. Cảm ơn bạn đã dành thời gian tham gia buổi hôm nay. Như đã trao đổi, chúng ta sẽ có một phiên về System Design.

(duthaho): Dạ, em chào anh Khoa. Em đã sẵn sàng ạ.

(Anh Khoa): Tốt. Chúng ta bắt đầu luôn nhé. Giả sử hệ thống của bạn là một nền tảng lưu trữ media, tương tự như Google Drive hoặc Dropbox. Người dùng lưu trữ hàng triệu file audio/video trên đó. Yêu cầu nghiệp vụ mới là: “Người dùng muốn có một nút ‘Bulk Download’. Họ có thể chọn hàng nghìn file một lúc—trường hợp xấu nhất có thể lên đến 500GB—và hệ thống phải nén các file này lại và cho phép họ tải về.”

Bạn sẽ thiết kế tính năng này như thế nào?

(duthaho): Dạ, đây là một case study rất hay ạ. Trước khi đưa ra giải pháp, em xin phép được đặt một vài câu hỏi để làm rõ yêu cầu, vì các yêu cầu này sẽ ảnh hưởng trực tiếp đến lựa chọn kiến trúc.

1. Về chức năng: Các file nguồn này đang được lưu trữ ở đâu? Trên server của mình hay trên một object storage như S3 ạ?

2. Về phi chức năng (NFR): Người dùng có thể chờ bao lâu? Họ nhấn nút và chờ màn hình loading (đồng bộ), hay họ chấp nhận nhận thông báo sau (bất đồng bộ)? Với 500GB thì em đoán chắc chắn là bất đồng bộ.

3. Về tải (Load): Tần suất sử dụng tính năng này có cao không? Ví dụ, chúng ta có bao nhiêu request “Bulk Download” đồng thời trong một phút?

4. Về đầu ra: Yêu cầu là “1 hoặc nhiều file zip”. Logic chia file zip là gì? Ví dụ: chia theo mỗi 10GB, hay cứ nén thành một file lớn duy nhất?

(Anh Khoa): Rất tốt, đó chính xác là những câu hỏi tôi mong đợi. Chúng ta hãy giả định thế này:

1. File đang nằm trên AWS S3.

2. Chính xác, đây phải là một quy trình bất đồng bộ (asynchronous). Người dùng không phải chờ.

3. Tần suất ở mức trung bình, khoảng 100-200 request/phút.

4. Hiện tại, cứ gộp thành một file zip lớn nhất có thể. Nếu có vấn đề, chúng ta sẽ tính đến việc chia nhỏ sau.

Mời bạn trình bày kiến trúc tổng quan.

(duthaho): Dạ, với các yêu cầu này, em sẽ đề xuất một kiến trúc xử lý nền (background processing) sử dụng Message Queue.

Luồng hoạt động sẽ như sau:

1. Client gọi đến API Server với danh sách các file ID cần nén.

2. API Server sẽ không xử lý ngay. Thay vào đó, nó sẽ:

   • Tạo một job_id.

   • Lưu thông tin job (danh sách file, user_id, status là PENDING) vào một Job Database (ví dụ DynamoDB hoặc PostgreSQL).

   • Đẩy một message chứa job_id vào một Message Queue (ví dụ AWS SQS).

   • Trả về job_id cho client ngay lập tức.

3. Client sẽ dùng job_id này để polling (hỏi) API, hoặc chúng ta có thể nâng cấp dùng WebSocket để đẩy (push) trạng thái real-time.

4. Một cụm Worker Service (có thể là các container trên ECS/Kubernetes) sẽ lắng nghe từ Queue.

5. Một worker nhận được job_id, nó sẽ cập nhật status trong DB thành PROCESSING.

6. Worker thực hiện việc nén, sau đó upload file zip kết quả lên S3.

7. Cuối cùng, worker cập nhật status thành COMPLETED và lưu lại URL của file zip.

(Anh Khoa): Ok, kiến trúc tổng quan này khá chuẩn. Giờ chúng ta đi sâu vào điểm mấu chốt. Con worker của bạn sẽ xử lý 500GB dữ liệu như thế nào mà không bị Out Of Memory (OOM)?

(duthaho): Dạ, đây là điểm mấu chốt của bài toán. Tuyệt đối không được tải toàn bộ 500GB về bộ nhớ của worker. Em sẽ sử dụng kỹ thuật Streaming.

Luồng xử lý của worker sẽ là:

1. Mở một Write Stream (luồng ghi) để tạo file zip (có thể ghi tạm ra đĩa của worker).

2. Với mỗi file trong danh sách:

   • Mở một Read Stream (luồng đọc) từ S3.

   • Đọc từng chunk nhỏ (ví dụ 10MB) từ stream S3.

   • Nén (compress) chunk đó.

   • Ghi (pipe) chunk đã nén vào Write Stream của file zip.

3. Sau khi lặp hết các file, worker sẽ đóng stream zip lại.

4. Upload file zip tạm đó lên S3.

Bằng cách này, bộ nhớ sử dụng tại mọi thời điểm chỉ bằng kích thước của chunk (10MB) chứ không phải 500GB.

(Anh Khoa): Tốt. Giờ tôi thêm một yếu tố phức tạp. Giả sử các file người dùng chọn không chỉ nằm trên S3 của chúng ta, mà còn có thể đến từ các nguồn bên ngoài, ví dụ: một link HTTP công khai, hoặc từ Google Drive của họ. Hệ thống của bạn sẽ thay đổi thế nào?

(duthaho): Dạ, khi làm việc với nhiều nguồn dữ liệu khác nhau, code của worker rất dễ bị rối bởi các câu if-else. Để giải quyết, em sẽ áp dụng Adapter Pattern.

1. Em sẽ định nghĩa một interface chung, ví dụ IStreamReader, với các phương thức chuẩn như open(), read(chunk_size), close().

2. Sau đó, em sẽ tạo các class “adapter” cụ thể cho từng nguồn: S3StreamReader, HttpStreamReader, GoogleDriveStreamReader...

3. Khi worker nhận job, một Factory sẽ xem source_type (là ‘s3’, ‘http’, hay ‘gdrive’) để khởi tạo các đối tượng Adapter tương ứng.

4. Logic nén file của worker sẽ không thay đổi. Nó chỉ làm việc với interface IStreamReader chung mà không cần quan tâm chi tiết file đến từ đâu.

(Anh Khoa): Rất hay. Nhưng điều đó dẫn đến một vấn đề mới. Giả sử 99 file trên S3 của ta rất nhanh, nhưng có 1 file 50GB nằm trên một server HTTP chậm ở châu Âu. Nó sẽ trở thành bottleneck (nút thắt cổ chai) và “chặn” toàn bộ job trong nhiều giờ. Bạn xử lý sao?

(duthaho): Đây là một vấnê đề về hiệu năng. Nếu server HTTP đó hỗ trợ HTTP Range Requests (cho phép tải từng phần), em sẽ áp dụng kỹ thuật Parallel Chunking (chia nhỏ song song).

Một Orchestrator (bộ điều phối) sẽ thay thế worker đơn giản.

1. Orchestrator sẽ thấy file 50GB này và chia nó thành 50 sub-task, mỗi sub-task xử lý 1GB.

2. Nó đẩy 50 sub-task này vào Queue.

3. Nhiều worker sẽ cùng lúc lấy các sub-task này về, download và nén song song các phần.

4. Kết quả sẽ là 50 file zip nhỏ.

5. Orchestrator sẽ theo dõi khi nào cả 50 sub-task hoàn thành và cung cấp cho người dùng một danh sách 50 file zip đó (thay vì cố gắng merge chúng lại, vốn cũng rất tốn kém).

(Anh Khoa): Ok, tôi thích ý tưởng đó. Giờ là câu hỏi cuối cùng về độ tin cậy. Giả sử trong 50 sub-task đó, có một sub-task liên tục bị lỗi. Worker thử lại (retry) nhiều lần vẫn lỗi. Chúng ta không thể để nó retry mãi, vừa tốn tài nguyên, vừa có thể làm sập server của đối tác (nếu là lỗi 429). Bạn sẽ thiết kế cơ chế chịu lỗi (fault tolerance) như thế nào?

(duthaho): Dạ, đối với xử lý lỗi tinh vi, em sẽ kết hợp 3 pattern:

1. Exponential Backoff: Khi có lỗi, worker sẽ không retry ngay. Nó sẽ đợi 1s, rồi 2s, 4s, 8s... Điều này giúp hệ thống “thở” và tránh tạo bão retry.

2. Phân tích mã lỗi: Khi retry, worker sẽ kiểm tra mã lỗi. Nếu là lỗi 404 (Not Found) hay 403 (Forbidden), đây là lỗi vĩnh viễn, việc retry là vô ích -> worker sẽ báo lỗi ngay. Nếu là 429 (Too Many Requests), logic backoff sẽ tự nhiên giúp giảm tải.

3. Circuit Breaker Pattern: Nếu một nguồn (ví dụ: server HTTP ở châu Âu) liên tục trả về lỗi 500, Orchestrator sẽ kích hoạt “ngắt mạch”. Tức là nó sẽ chủ động từ chối mọi sub-task mới đến nguồn đó trong 5 phút. Điều này bảo vệ hệ thống của ta khỏi lãng phí tài nguyên và bảo vệ cả hệ thống của đối tác.

Sau khi Circuit Breaker được kích hoạt, Orchestrator sẽ đánh dấu toàn bộ job là FAILED và thông báo rõ cho người dùng là “Không thể xử lý file X do nguồn Y gặp sự cố”.

(Anh Khoa): Rất tốt, duthaho. Bạn đã phân tích vấn đề rất có cấu trúc, đi từ yêu cầu cơ bản, xây dựng kiến trúc, sau đó đào sâu vào các vấn đề khó như quản lý bộ nhớ, mở rộng hệ thống và thiết kế chịu lỗi. Câu trả lời của bạn rất rõ ràng và logic.

Cảm ơn bạn. Buổi phỏng vấn của chúng ta kết thúc ở đây. Bạn có câu hỏi nào cho tôi không?

(duthaho): Dạ, em cảm ơn anh Khoa. Em muốn hỏi là trong các dự án thực tế tại công ty, văn hóa kỹ thuật của mình ưu tiên việc dùng các managed service (như SQS, DynamoDB) để phát triển nhanh, hay ưu tiên việc tự vận hành (self-hosted) các giải pháp open-source (như RabbitMQ, PostgreSQL) để tối ưu chi phí về lâu dài ạ?

(Anh Khoa): ...

Project thực tế của mọi người như thế nào, hãy comment trả lời giúp anh Khoa nhé :D

Bắt đầu buổi phỏng vấn

(Anh Minh bắt đầu cuộc gọi, mỉm cười thân thiện)

Anh Minh: Chào duthaho, anh là Minh. Cảm ơn em đã dành thời gian tham gia buổi phỏng vấn hôm nay. Em nghe rõ anh nói chứ?

duthaho: Dạ em chào anh Minh, em nghe rất rõ ạ. Em cũng cảm ơn anh đã tạo điều kiện cho em có buổi trao đổi này.

Anh Minh: Ok tốt rồi. Hôm nay chúng ta sẽ có một bài toán về thiết kế hệ thống. Anh muốn tìm hiểu về cách em tư duy, phân tích vấn đề và đưa ra các lựa chọn kiến trúc. Em cứ thoải mái trao đổi, vẽ vời trên whiteboard nhé. Đây là cuộc thảo luận hai chiều thôi.

duthaho: Dạ vâng ạ.

Anh Minh: Được rồi, bài toán của chúng ta như sau: "Hãy thiết kế một dịch vụ có khả năng tạo ra các ID duy nhất (unique ID) cho một hệ thống quy mô lớn, ví dụ như YouTube hoặc một sàn thương mại điện tử. Yêu cầu là ID phải ngắn gọn và hệ thống phải đáp ứng được lưu lượng truy cập rất cao."

Em đã hiểu rõ đề bài chưa?

Giai đoạn 1: Làm rõ yêu cầu

duthaho: Dạ em đã hiểu đề bài. Trước khi đi vào giải pháp, em xin phép hỏi một vài câu để làm rõ hơn các yêu cầu của hệ thống ạ.

Anh Minh: Rất tốt, em hỏi đi.

duthaho:

1. Về chức năng: ID này sẽ được dùng ở đâu ạ? Ví dụ như trong URL hay chỉ trong nội bộ hệ thống? Điều này sẽ ảnh hưởng đến định dạng của ID, ví dụ nó có cần phải "URL-safe" không?

2. Về phi chức năng:

   • Thông lượng (Throughput): Khi anh nói "lưu lượng rất cao", con số cụ thể chúng ta hướng đến là khoảng bao nhiêu ID mỗi giây ạ? Ví dụ 10,000 hay 100,000 ID/giây?

   • Độ trễ (Latency): Thời gian phản hồi để tạo một ID có yêu cầu khắt khe không ạ? Ví dụ dưới 10ms hay 50ms?

   • Tính duy nhất: Yêu cầu là duy nhất 100% hay chỉ cần xác suất trùng lặp cực kỳ thấp là được ạ?

   • Thứ tự: ID được tạo ra có cần phải sắp xếp được theo thời gian không ạ?

Anh Minh: (Gật đầu, tỏ vẻ hài lòng) Những câu hỏi rất xác đáng. Giả sử các yêu cầu cụ thể như sau nhé:

• ID cần phải ngắn và an toàn cho URL (URL-safe).

• Thông lượng mục tiêu là 50,000 ID/giây ở mức đỉnh điểm.

• Độ trễ phải dưới 10ms.

• Yêu cầu duy nhất 100%.

• Việc sắp xếp được theo thời gian là một lợi thế lớn, nhưng không bắt buộc.

Giai đoạn 2: Thảo luận các hướng tiếp cận

duthaho: Dạ em cảm ơn anh. Với các yêu cầu này, em nghĩ đến một vài hướng tiếp cận với các sự đánh đổi khác nhau.

Đầu tiên là phương án đơn giản nhất: dùng Auto-Increment của Database.

• Ưu điểm: Rất dễ triển khai, đảm bảo duy nhất và tuần tự.

• Nhược điểm: Đây sẽ là một nút cổ chai (bottleneck) cực lớn và là điểm lỗi duy nhất (Single Point of Failure). Nó không thể đáp ứng được 50,000 request/giây. Do đó, em xin phép loại phương án này.

Anh Minh: Anh đồng ý. Vậy còn phương án nào khác không?

duthaho: Dạ có ạ. Một phương án phân tán hoàn toàn là dùng UUID.

• Ưu điểm: Không cần một dịch vụ tập trung, các máy chủ tự sinh ID nên khả năng mở rộng là vô hạn, không có điểm lỗi duy nhất.

• Nhược điểm: UUID quá dài (36 ký tự), không đáp ứng yêu cầu "ID ngắn gọn". Hơn nữa, UUID phiên bản 4 phổ biến thì hoàn toàn ngẫu nhiên, không sắp xếp được theo thời gian, gây ảnh hưởng xấu đến hiệu năng index của database.

Anh Minh: Ok. Vậy có vẻ UUID cũng chưa phù hợp.

duthaho: Dạ đúng ạ. Để cân bằng các yếu tố, em đề xuất xây dựng một dịch vụ tạo ID tập trung (Centralized Service). Có hai hướng triển khai phổ biến cho dịch vụ này:

1. Dùng Redis INCR: Ta có thể dùng lệnh INCR nguyên tử của Redis để tạo ra một chuỗi số tuần tự. Sau đó mã hóa số này sang Base62 để có ID ngắn và URL-safe.

2. Dùng thuật toán kiểu Twitter Snowflake: Xây dựng một dịch vụ sinh ra số 64-bit duy nhất, sau đó cũng mã hóa sang Base62.

Anh Minh: Rất hay. Em có thể phân tích sâu hơn về ưu và nhược điểm của việc dùng Redis và Snowflake không?

duthaho: Dạ được ạ.

• Với Redis INCR:

  • Ưu điểm: Rất nhanh (in-memory), thông lượng cao trên một node, triển khai đơn giản hơn Snowflake.

  • Nhược điểm: Vẫn có nguy cơ là điểm lỗi duy nhất. Mặc dù có thể dùng Redis Sentinel/Cluster để tăng tính sẵn sàng, nhưng vẫn có độ trễ khi failover. Quan trọng nhất, khả năng mở rộng bị giới hạn bởi năng lực của một node Redis duy nhất, vì lệnh INCR trên một key không thể phân tán ra nhiều node.

• Với Snowflake:

  • Ưu điểm: Được thiết kế để mở rộng theo chiều ngang và có tính sẵn sàng cao ngay từ đầu. ID sinh ra có thể sắp xếp theo thời gian, đây là lợi thế rất lớn cho việc truy vấn và phân tích dữ liệu. Tổng thông lượng của hệ thống rất lớn.

  • Nhược điểm: Phức tạp hơn trong việc triển khai và vận hành, đòi hỏi các thành phần phụ trợ như Zookeeper để quản lý machine ID và NTP để đồng bộ thời gian.

Với yêu cầu về thông lượng lớn và tính sẵn sàng cao, em nghĩ phương án Snowflake là phù hợp nhất cho bài toán này trong dài hạn.

Giai đoạn 3: Đi sâu vào giải pháp

Anh Minh: Anh đồng ý với lựa chọn của em. Em có thể mô tả cấu trúc của một ID theo kiểu Snowflake và kiến trúc tổng quan của dịch vụ này không?

duthaho: Dạ. ID 64-bit của Snowflake được cấu thành từ 3 phần chính ạ:

1. Timestamp (41 bits): Số mili giây tính từ một mốc thời gian (epoch), cho phép hệ thống hoạt động trong ~69 năm.

2. Machine ID (10 bits): Mã định danh cho máy chủ tạo ID, cho phép có tối đa 1024 máy chủ trong cụm.

3. Sequence Number (12 bits): Số thứ tự cho các ID được tạo ra trong cùng 1 mili giây trên cùng 1 máy chủ, cho phép tạo tối đa 4096 ID/ms/máy.

Về kiến trúc tổng quan, hệ thống sẽ bao gồm:

• Một cụm các ID Generator Server: Chạy logic tạo ID Snowflake.

• Một Load Balancer: Đứng trước để phân phối request.

• Một dịch vụ Coordination (như Zookeeper/Etcd): Để đảm bảo mỗi Generator Server khi khởi động sẽ được cấp một Machine ID duy nhất.

Anh Minh: Em đã đề cập đến 2 vấn đề vận hành khá khó của Snowflake. Một là quản lý Machine ID, hai là đồng bộ thời gian. Em sẽ giải quyết chúng như thế nào?

duthaho: Dạ, với Machine ID, em sẽ dùng Zookeeper. Mỗi server khi khởi động sẽ kết nối tới Zookeeper và đăng ký một "ephemeral node" để nhận một Machine ID duy nhất từ một pool đã định sẵn. Vì là ephemeral node, nếu server bị mất kết nối, Zookeeper sẽ tự động thu hồi Machine ID đó để cấp phát lại.

Còn với đồng bộ thời gian, tất cả các server trong hệ thống bắt buộc phải được cài đặt và cấu hình dịch vụ NTP (Network Time Protocol) để đảm bảo đồng hồ hệ thống luôn được đồng bộ chính xác.

Anh Minh: Rất rõ ràng. Giờ là một câu hỏi mở rộng. Giả sử hệ thống phát triển, và chúng ta cần nhiều hơn 1024 máy chủ tạo ID. Em sẽ làm gì?

duthaho: Dạ đây là một bài toán đánh đổi kinh điển. Vì không gian 64-bit là cố định, để tăng số bits cho Machine ID (ví dụ lên 11 bits để có 2048 máy), em buộc phải lấy 1 bit từ nơi khác.

• Lựa chọn 1: Lấy 1 bit từ Sequence Number. Machine ID sẽ là 11 bits, Sequence còn 11 bits.

  • Đánh đổi: Thông lượng trên mỗi máy giảm còn 2048 ID/ms. Tuy nhiên, tổng thông lượng hệ thống vẫn tăng. Lựa chọn này thường an toàn hơn.

• Lựa chọn 2: Lấy 1 bit từ Timestamp. Machine ID là 11 bits, Timestamp còn 40 bits.

  • Đánh đổi: Tuổi thọ của hệ thống giảm một nửa, còn khoảng 34.5 năm. Đây là rủi ro lớn trong dài hạn.

Vì vậy, em sẽ chọn phương án 1, hy sinh một chút thông lượng trên từng node để đổi lấy khả năng mở rộng hệ thống và giữ được tuổi thọ lâu dài.

Giai đoạn 4: Kết thúc

Anh Minh: Cảm ơn duthaho. Phần trình bày của em rất có cấu trúc, mạch lạc và cho thấy sự hiểu biết sâu về các trade-off trong thiết kế hệ thống. Anh không còn câu hỏi nào thêm. Em có câu hỏi nào cho anh không?

duthaho: Dạ hiện tại thì em chưa có câu hỏi nào ạ. Em cảm ơn anh Minh đã dành thời gian ạ.

Anh Minh: Ok, cảm ơn em. Bộ phận tuyển dụng sẽ liên hệ với em về kết quả trong vài ngày tới nhé. Chào em.

duthaho: Dạ, em chào anh.