DEV Community: Nghề không nhiều chẳng sắc

Logging — Request Logging

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:55 +0000

Request logging: vì sao mỗi log line phải có request id, và structured log cứu debug thế nào khi có sự cố production

Request logging không phải là in console.log('got a request') cho vui. Nó là dấu vết duy nhất còn lại khi một request đã đi qua service, đi qua vài downstream, gặp lỗi, và bị đóng socket. Nếu log không có gì để nối lại các dòng thuộc cùng một request — không có requestId, không có traceId — thì log của một service RPS trung bình biến thành một mớ text xen kẽ giữa hàng chục request đồng thời, và câu hỏi "request X đã đi tới đâu, fail ở service nào" trở thành không trả lời được. Structured log (mỗi dòng là một JSON object với field cố định) + một correlation id truyền qua toàn bộ pipeline chính là cái làm log có thể query được, thay vì grep mù. Hai framework Express và Fastify tiếp cận khác nhau: Fastify tích hợp pino sẵn và tự sinh req.id, Express phải tự dán qua pino-http hoặc middleware tay. Nhưng cả hai đều vỡ theo cùng một kiểu khi correlation id bị đứt giữa các service.

Cơ chế hoạt động

Ba miếng ghép: (1) một structured logger — thường là pino trong ecosystem Node vì nó ghi NDJSON và có async destination, (2) một cơ chế sinh/nhận requestId, (3) một cách propagate id đó qua async work và qua HTTP call sang service khác.

pino là JSON logger tối giản: mỗi lời gọi logger.info({...}, 'message') xuất một dòng NDJSON ra một WritableStream (mặc định là stdout). Log level là số (trace=10, debug=20, info=30, warn=40, error=50, fatal=60, theo pino docs), và có child logger — logger.child({ reqId }) tạo một logger mới bind sẵn các field, mọi log line từ child đều có reqId mà không phải truyền tay.

Với Fastify, chỉ cần logger: true là có pino và request logging tự động — Fastify sinh request.id (mặc định là monotonic counter, đổi được qua option genReqId) và log một cặp dòng "incoming request" / "request completed" cho mỗi request. Trong handler, request.log là child logger đã bind reqId:

import Fastify from 'fastify'
import crypto from 'node:crypto'

const app = Fastify({
  logger: {
    level: process.env.LOG_LEVEL ?? 'info',
    redact: ['req.headers.authorization', 'req.headers.cookie', '*.password'],
  },
  // Ưu tiên id từ upstream nếu có, không thì sinh mới
  genReqId: (req) =>
    req.headers['x-request-id'] ??
    req.headers['traceparent']?.split('-')[1] ??
    crypto.randomUUID(),
  requestIdHeader: 'x-request-id',
  requestIdLogLabel: 'reqId',
})

app.get('/orders/:id', async (req, reply) => {
  req.log.info({ orderId: req.params.id }, 'looking up order')
  const order = await app.db.orders.findById(req.params.id)
  reply.header('x-request-id', req.id)
  return order
})

Với Express, không có logger tích hợp — dùng pino-http, một Express-compatible middleware do cùng maintainer của pino ship. pino-http gắn req.log và req.id, tự log khi res.on('finish') với responseTime, statusCode, req, res đã được serialize gọn qua pino.stdSerializers:

import express from 'express'
import pinoHttp from 'pino-http'
import crypto from 'node:crypto'

const app = express()
app.use(pinoHttp({
  level: process.env.LOG_LEVEL ?? 'info',
  genReqId: (req, res) => {
    const id = req.headers['x-request-id'] ?? crypto.randomUUID()
    res.setHeader('x-request-id', id)
    return id
  },
  customLogLevel: (req, res, err) => {
    if (err || res.statusCode >= 500) return 'error'
    if (res.statusCode >= 400) return 'warn'
    return 'info'
  },
  redact: ['req.headers.authorization', 'req.headers.cookie'],
}))

app.get('/orders/:id', async (req, res) => {
  req.log.info({ orderId: req.params.id }, 'looking up order')
  const order = await db.orders.findById(req.params.id)
  res.json(order)
})

Miếng thứ ba — propagate id qua async work và qua HTTP call downstream — là chỗ hầu hết implementation vỡ. Node core có AsyncLocalStorage (module node:async_hooks) giữ context xuyên qua callback/promise mà không phải truyền tham số:

import { AsyncLocalStorage } from 'node:async_hooks'
export const ctx = new AsyncLocalStorage()

app.addHook('onRequest', (req, _reply, done) => {
  ctx.run({ reqId: req.id }, done)
})

// Ở tầng HTTP client — tự động gắn header khi gọi downstream
export async function fetchDownstream(url, init = {}) {
  const store = ctx.getStore()
  const headers = new Headers(init.headers)
  if (store?.reqId) headers.set('x-request-id', store.reqId)
  return fetch(url, { ...init, headers })
}

Cách "chuẩn" hơn là dùng W3C Trace Context (header traceparent, format 00-<trace-id>-<span-id>-<flags>, theo W3C Trace Context spec). OpenTelemetry SDK cho Node tự inject traceparent vào outgoing HTTP call và extract vào incoming request; log có thể bindings thêm trace_id/span_id để mọi dòng log tự động join được với trace. Đây là mặc định nếu service đã có OpenTelemetry — không phải viết tay.

Vấn đề gặp trong production

Failure mode 1: không có correlation id — không thể truy vết request qua service. Kịch bản: user báo checkout order #42871 fail. Log của service orders có dòng ERROR upstream timeout, log của service payments có dòng ERROR db connection lost cách đó 300ms. Có phải hai lỗi này cùng thuộc một request của user không? Không biết. Không có id chung để nối lại. Grep theo orderId cũng chỉ tìm được ở service orders — service payments không biết orderId là gì, nó chỉ nhận paymentIntentId. Nếu ngay từ đầu mọi service log kèm cùng một x-request-id (hoặc traceparent), query log aggregator theo reqId=abc123 ra đúng chuỗi dòng của một request qua mọi hop.

// SAI: log không có id gì để nối các dòng
app.post('/checkout', async (req, res) => {
  console.log('checkout started')
  const r = await fetch('http://payments/charge', { /* không gắn header id */ })
  if (!r.ok) console.log('payment failed', r.status)
  res.json({ ok: r.ok })
})

// ĐÚNG: sinh/nhận id ở edge, gắn vào log, propagate xuống downstream
app.post('/checkout', async (req, res) => {
  req.log.info({ userId: req.user.id }, 'checkout started')
  const r = await fetch('http://payments/charge', {
    headers: { 'x-request-id': req.id, 'content-type': 'application/json' },
    body: JSON.stringify({ /* ... */ }),
  })
  if (!r.ok) req.log.warn({ status: r.status }, 'payment failed')
  res.json({ ok: r.ok, requestId: req.id })
})

Failure mode 2: unstructured log — không query được. console.log('user ' + userId + ' bought ' + qty) trông đọc được nhưng không parse ngược lại thành field. Log aggregator (Elastic, Loki, Datadog) index theo field JSON; nếu log là plain string, chỉ còn full-text search. "Đếm số request lỗi 500 theo route trong 1h qua" biến thành parse regex trên free text, và grep không phân biệt được error trong error message với error trong stack trace. Structured log giải quyết bằng cách mỗi log line là một JSON có schema:

// SAI: string concat, không có level, không có id, mất field
console.log(`user ${userId} bought ${qty} of ${sku} in ${ms}ms`)

// ĐÚNG: object + message, có level, có reqId (qua child logger)
req.log.info({ userId, qty, sku, durationMs: ms }, 'purchase completed')
// -> {"level":30,"time":...,"reqId":"...","userId":"u1","qty":2,"sku":"...","durationMs":47,"msg":"purchase completed"}

Failure mode 3: log PII/secret ra file — leak dữ liệu. Log request body/headers thô sẽ ghi cả Authorization: Bearer ..., Cookie: session=..., password, số thẻ. Log thường được ship đi khắp nơi (Kafka, S3, log aggregator, backup); một khi PII lọt vào chain đó, khó thu hồi. pino có option redact (theo pino docs), nhận array path để thay bằng [Redacted] trước khi ghi:

// SAI: log toàn bộ req sẽ chứa Authorization/Cookie header
logger.info({ req }, 'incoming')

// ĐÚNG: redact path nhạy cảm ở tầng logger, không dựa vào code call site
const logger = pino({
  redact: {
    paths: ['req.headers.authorization', 'req.headers.cookie', '*.password', '*.creditCard'],
    censor: '[Redacted]',
  },
})

Failure mode 4: sync log chặn event loop. Ghi log đồng bộ (fs.writeSync, hay console.log khi stdout là file/pipe blocking) chặn thread cho tới khi kernel nhận xong. Ở RPS cao, mỗi request đóng góp vài log line, tổng độ trễ log ăn thẳng vào p99. pino mặc định ghi async qua sonic-boom, nhưng nếu dựng pino.destination({ sync: true }) (hoặc dùng transport sai cách), toàn bộ log biến thành blocking. Với high-throughput service, để pino ở chế độ async mặc định, hoặc dùng pino.transport() chạy trên worker thread riêng.

Failure mode 5: correlation id trust boundary. Nhận x-request-id từ client public internet mà không validate: attacker có thể inject id trùng để làm nhiễu log, hoặc chèn ký tự lạ (newline) để log injection. Rule: ở edge (API gateway hoặc service ngoài cùng), sinh id mới; chỉ trust header id từ upstream nội bộ đã xác thực (service mesh, LB) — hoặc validate format (UUID/ULID) trước khi dùng.

Cách debug và monitor

Triệu chứng cần đọc log tốt: user báo "request fail lúc 14:23", user chỉ có thể nhớ thời điểm và một phần URL; hoặc dashboard alert 5xx rate spike nhưng không biết request nào là root cause. Cách tiếp cận:

Query theo reqId trong log aggregator. Trả x-request-id ra response header và hiển thị nó ở error page cho user, để user copy-paste id vào bug report. Ở Elastic/Loki/Datadog, query reqId:"abc-123" trả về toàn bộ log line của request đó — qua mọi service, đã sort theo timestamp.
Join log với trace. Nếu đã bật OpenTelemetry, log line có trace_id/span_id, ngược lại trace có attributes.http.request.id. Bấm từ dòng log sang trace UI (Grafana Tempo, Jaeger, Honeycomb, Datadog APM) thấy chính xác downstream call nào chậm.
Metric từ log. Đếm log level error/warn theo route và emit thành metric (Loki LogQL query theo level, hoặc convert log → metric qua promtail/vector). Alert khi error rate vượt baseline.
Log volume monitoring. Log volume là chi phí thật (ingest, storage, egress). Theo dõi bytes/sec log mỗi service; một spike volume thường có nghĩa hoặc là stack trace loop (một error đang loop nhanh), hoặc là ai đó bật debug log ở production quên tắt. Đặt sample cho log info khi RPS quá cao (level: 'warn' ở prod, hoặc chỉ log 1/N request thành công).
Health của logging pipeline. Nếu log destination (Fluent Bit, Vector, Filebeat) đứng, log vẫn ghi ra stdout nhưng không được ship — service vẫn chạy nhưng "mù". Monitor pipeline lag riêng, không phải chỉ log volume ở đích.

Rule phòng ngừa cứng: (1) mọi service bắt buộc có requestId/traceId trong mọi log line — enforce qua template logger, không phải dựa vào từng call site nhớ; (2) không dùng console.log trong code production — lint rule cấm (no-console của ESLint); (3) redact tập trung ở logger config, không phải ở call site; (4) trả x-request-id ra response để user báo bug có id; (5) LOG_LEVEL phải configurable qua env — thay đổi mà không phải redeploy.

Tradeoff

Structured log dễ query, dễ join với trace, dễ redact — nhưng tăng volume so với plain text. Một dòng "user 1 bought 2" (~18 bytes) biến thành một JSON object với level, time, reqId, userId, qty, msg (~100+ bytes). Ở service RPS cao, chênh lệch này nhân lên thành GB/ngày và ăn ngân sách log ingest thật (Datadog/Splunk tính tiền theo GB). Bù lại: query time giảm mạnh vì aggregator index được field, không phải full-text scan; và cost của một sự cố production dài hơn vì grep mù thường lớn hơn cost log volume nhiều lần.

Correlation id truyền qua header có cost: mỗi service phải nhớ đọc + gắn lại khi gọi downstream — quên một chỗ là đứt chuỗi. Automation qua OpenTelemetry instrumentation hoặc middleware chung giải quyết, nhưng thêm dependency và một tầng abstraction. Tự làm bằng AsyncLocalStorage nhẹ hơn nhưng phải wrap tất cả outgoing HTTP client.

Async log giảm latency trên hot path nhưng có risk mất log cuối cùng khi process crash — buffer chưa flush. pino có pino.final() (theo pino docs) để flush trong uncaughtException/SIGTERM handler. Sync log an toàn hơn nhưng chặn event loop; chỉ dùng ở CLI/script ngắn, không dùng ở server RPS cao.

Rule of thumb: mặc định structured JSON log + async destination + một correlation id (ưu tiên W3C traceparent nếu có OpenTelemetry, không thì x-request-id) sinh ở edge và propagate xuyên suốt; info level ở prod với sample nếu cần, debug chỉ bật tạm qua env; redact ở logger config; trả id ra response header. Đừng tối ưu volume trước khi có sự cố đầu tiên buộc phải grep — bài học từ postmortem là "wish we had reqId" nhiều hơn "wish we logged less".

Câu hỏi phỏng vấn

Vì sao cần request id trong log, và cụ thể propagate nó qua các service như thế nào?

Vì một service RPS trung bình có nhiều request đồng thời, log line từ các request khác nhau xen kẽ nhau trong file/stream. Không có một field chung để nối các dòng thuộc cùng một request, thì "request X đã đi qua đâu, fail ở step nào" không trả lời được — chỉ còn grep mù. Cụ thể: ở edge service (service ngoài cùng nhận request từ client), sinh một requestId (UUID/ULID) hoặc lấy từ header x-request-id nếu upstream đã có; bind vào child logger (logger.child({ reqId }) với pino, hoặc request.log sẵn có với Fastify) để mọi log line trong scope request đều mang id. Khi gọi downstream service, gắn id vào request header (x-request-id, hoặc chuẩn hơn là W3C traceparent); downstream đọc header đó, dùng lại làm reqId của nó — chuỗi id không đứt qua network hop. Xuyên qua async work trong cùng process, dùng AsyncLocalStorage (Node core) để giữ context, không phải truyền reqId qua từng argument. Điểm ăn điểm là gọi tên hai hậu quả production: (a) không có correlation id thì incident postmortem chỉ join được manually theo timestamp — cực kỳ chậm và dễ sai khi có concurrent request; (b) nhận id từ public internet không validate là log injection vector — id phải sinh mới ở edge, chỉ trust từ upstream nội bộ; và một hậu quả về monitoring — log volume tăng vì mỗi line có thêm field, nhưng đây là chi phí phải trả để log query được thay vì phải grep mù. Bonus: trả x-request-id ra response header để user báo bug kèm id, khỏi phải hỏi "khoảng lúc mấy giờ".

Hands-on

Dựng một chain hai service Fastify để tái hiện scenario "log không có correlation id" rồi sửa, rồi query theo id.

Chuẩn bị:

mkdir req-logging && cd req-logging
npm init -y
npm pkg set type=module
npm i fastify pino pino-pretty

Tạo service-a.mjs (edge, gọi service-b):

import Fastify from 'fastify'
import crypto from 'node:crypto'

const app = Fastify({
  logger: {
    level: 'info',
    redact: ['req.headers.authorization', 'req.headers.cookie'],
  },
  genReqId: (req) =>
    req.headers['x-request-id'] ?? crypto.randomUUID(),
  requestIdHeader: 'x-request-id',
  requestIdLogLabel: 'reqId',
})

app.get('/checkout/:orderId', async (req, reply) => {
  req.log.info({ orderId: req.params.orderId }, 'checkout starting')

  // Gắn requestId vào call downstream — đây là điểm dễ quên
  const url = 'http://localhost:3102/charge/' + req.params.orderId
  const r = await fetch(url, {
    headers: { 'x-request-id': req.id },
  })
  const body = await r.json()

  if (!r.ok) req.log.warn({ status: r.status, body }, 'charge failed')
  reply.header('x-request-id', req.id)
  return { ok: r.ok, orderId: req.params.orderId, requestId: req.id, downstream: body }
})

await app.listen({ port: 3101, host: '0.0.0.0' })

Tạo service-b.mjs (downstream, fail ngẫu nhiên):

import Fastify from 'fastify'
import crypto from 'node:crypto'

const app = Fastify({
  logger: { level: 'info' },
  genReqId: (req) =>
    req.headers['x-request-id'] ?? crypto.randomUUID(),
  requestIdHeader: 'x-request-id',
  requestIdLogLabel: 'reqId',
})

app.get('/charge/:orderId', async (req, reply) => {
  req.log.info({ orderId: req.params.orderId }, 'charge received')
  // Simulate downstream latency + ~30% failure
  await new Promise(r => setTimeout(r, 20 + Math.random() * 80))
  if (Math.random() < 0.3) {
    req.log.error({ orderId: req.params.orderId }, 'db connection lost')
    return reply.code(500).send({ error: 'db_down' })
  }
  return { charged: true, orderId: req.params.orderId }
})

await app.listen({ port: 3102, host: '0.0.0.0' })

Chạy song song, ghi log ra file để grep sau:

node service-a.mjs 2>&1 | tee -a /tmp/a.log &
node service-b.mjs 2>&1 | tee -a /tmp/b.log &

# Bắn 50 request, mỗi request là một orderId khác
for i in $(seq 1 50); do
  curl -s "http://localhost:3101/checkout/order-$i" > /dev/null &
done
wait

Chọn một request đã fail (theo response {"ok":false,...}) — ví dụ requestId=abc-def-.... Query log của cả hai service theo id đó:

grep '"reqId":"abc-def-..."' /tmp/a.log /tmp/b.log | jq -s 'sort_by(.time)'

Sẽ ra chuỗi log line từ service-a → service-b → error → response, theo đúng thứ tự thời gian, cho đúng một request. Đây là điều không thể làm được nếu không truyền x-request-id sang downstream.

Sau đó, tái hiện failure mode 1 bằng cách xóa dòng headers: { 'x-request-id': req.id } trong service-a. Chạy lại và thử query: service-b sinh id mới cho mỗi request, không match id của service-a — chain bị đứt. Grep theo reqId chỉ ra dòng của service-a; grep theo orderId may ra được nhưng chỉ khi cả hai service tình cờ log cùng field đó.

Cuối cùng, thử log volume: bench và đo size log sinh ra:

# Bench với autocannon để xem log volume và độ trễ
npx autocannon -c 20 -d 10 http://localhost:3101/checkout/bench
wc -c /tmp/a.log /tmp/b.log   # size log sinh ra trong 10s

Bật LOG_LEVEL=warn (sửa level: process.env.LOG_LEVEL ?? 'info' trong config) và chạy lại — volume log giảm mạnh vì info bị bỏ qua, chỉ còn warn/error. Đây là cần chỉnh khi service RPS cao và ngân sách log ingest bị vượt: giảm level ở hot path, giữ error log nguyên vẹn.

Async Error Handling — Async Route

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:51 +0000

Async route: vì sao Promise reject trong Express 4 không tới error middleware, và cách Fastify tự bắt lỗi

Một async route handler trông giống một handler bình thường, nhưng cơ chế truyền lỗi của nó khác hẳn. Express 4 bọc lời gọi handler bằng try/catch đồng bộ; một hàm async return về một Promise trước khi Promise đó settle, nên try/catch đồng bộ không bắt được rejection. Kết quả: lỗi rơi ra khỏi handler dưới dạng unhandledRejection, không tới error middleware, không được gửi thành 500 JSON, và từ Node 15 mặc định làm process crash. Fastify đi hướng khác — pipeline hook tự await handler, rejection được framework bắt và chuyển tới setErrorHandler. Hiểu điểm khác biệt này giải thích vì sao cùng một dòng code await db.query(...) lại có hai hệ quả production hoàn toàn khác nhau giữa hai framework.

Cơ chế hoạt động

Trong Express 4, Layer.handle_request gọi handler đồng bộ trong một khối try/catch. Nếu handler ném exception đồng bộ, catch được, forward qua next(err). Nhưng handler async không ném — nó return về một Promise. Đến khi Promise reject, control đã ra khỏi khối try/catch từ lâu:

// Đây là bản giản lược của cách Express 4 gọi handler:
try {
  const ret = handler(req, res, next)   // với async handler, ret là Promise (đã pending)
  // handler đã "return" — try/catch không còn hiệu lực với reject xảy ra sau
} catch (err) {
  next(err)                              // chỉ chạy khi handler ném đồng bộ
}

Vì Express 4 không await ret và cũng không ret.catch(next), một Promise reject không có bên nào bắt. Node emit unhandledRejection ở tầng process. Cách sửa chuẩn là wrapper:

// asyncHandler: bọc handler async, forward reject vào next(err)
export const asyncHandler = (fn) => (req, res, next) =>
  Promise.resolve(fn(req, res, next)).catch(next)

app.get('/orders/:id', asyncHandler(async (req, res) => {
  const order = await db.orders.findById(req.params.id)
  if (!order) { res.status(404).json({ error: 'not_found' }); return }
  res.json(order)
}))

Express 5 (bản major stable phát hành 2024) sửa vấn đề này ở tầng framework: theo Express docs mục "Migrating to Express 5", route/middleware trả về Promise reject sẽ tự bị forward vào error chain, không cần wrapper nữa. Nhưng phần lớn service production vẫn đang ở Express 4, nên wrapper vẫn là kiến thức bắt buộc.

Fastify không có vấn đề tương đương. Theo Fastify docs mục "Errors", pipeline hook await từng bước; nếu handler async reject (throw hay return rejected Promise đều được), Fastify bắt, dẫn qua hook onError rồi gọi error handler (setErrorHandler nếu có, mặc định trả JSON với statusCode):

app.setErrorHandler((err, req, reply) => {
  req.log.error({ err }, 'request failed')
  reply.status(err.statusCode ?? 500).send({ error: err.code ?? 'internal' })
})

app.get('/orders/:id', async (req, reply) => {
  const order = await app.db.orders.findById(req.params.id)
  if (!order) throw app.httpErrors.notFound()    // Fastify bắt, chuyển tới setErrorHandler
  return order
})

Vấn đề gặp trong production

Failure mode 1: async handler Express 4 không bọc — process crash. Đây là failure mode phổ biến nhất khi migrate từ callback sang async/await:

// SAI: Express 4 không bắt Promise reject từ handler async
app.get('/orders/:id', async (req, res) => {
  const order = await db.orders.findById(req.params.id) // reject nếu DB down
  res.json(order)
})

Khi db.orders.findById reject (DB timeout, connection pool exhausted, syntax error), handler return một Promise reject. Client thấy request treo cho tới khi socket timeout. Ở tầng process, Node emit unhandledRejection; từ Node 15 mặc định là --unhandled-rejections=throw (theo Node docs process event unhandledRejection), nghĩa là process crash. Trên K8s, pod bị OOM/crash-restart; một lỗi DB làm rơi cả instance. Sửa bằng wrapper asyncHandler (xem trên) hoặc dùng thư viện express-async-errors (monkey-patch Layer.handle_request để tự await) — thêm vào import 'express-async-errors' ở đầu app.

Failure mode 2: fire-and-forget bên trong handler. Cả trong Express lẫn Fastify, nếu bên trong handler có một async call không được await, framework không thấy Promise đó, không có bên nào bắt reject:

// SAI: emit event log không await, reject rơi vào void
app.post('/orders', asyncHandler(async (req, res) => {
  const order = await db.orders.create(req.body)
  auditLog.write({ event: 'order.created', orderId: order.id }) // async, không await, không .catch
  res.status(201).json(order)
}))

Nếu auditLog.write reject, không ai bắt — kể cả wrapper asyncHandler cũng bó tay vì handler đã return xong. Đây là lỗi bất kể framework. Sửa: await nếu cần chờ, hoặc .catch(err => log.error({ err }, 'audit failed')) nếu cố tình fire-and-forget để không block response.

Failure mode 3: try/catch nuốt lỗi rồi vẫn res.send bình thường. Ngược với failure mode 1: bọc try/catch quá rộng và không phản hồi đúng status:

// SAI: catch tất, nuốt lỗi, trả 200 với body rỗng
app.get('/orders/:id', asyncHandler(async (req, res) => {
  try {
    const order = await db.orders.findById(req.params.id)
    res.json(order)
  } catch (err) {
    res.json({})   // nuốt lỗi, client thấy 200 OK payload rỗng — monitor mù
  }
}))

Alerts không kích hoạt (status 200), nhưng downstream nhận payload rỗng và vỡ. Quy tắc: nếu bắt exception ở tầng handler, hoặc next(err) để error middleware xử lý thống nhất, hoặc res.status(...) với status thật (không phải 200). Đừng ép về 200 {}.

Failure mode 4: middleware async không bọc — treo request không log. Middleware async cũng bị đúng vấn đề như handler async trong Express 4:

// SAI: auth middleware async, verifyToken reject, không có bên bắt
app.use(async (req, _res, next) => {
  req.user = await verifyToken(req.headers.authorization)  // reject nếu token invalid
  next()
})

Reject không tới error middleware, request treo, unhandledRejection bắn. Sửa: bọc bằng cùng wrapper asyncHandler áp dụng cho middleware, hoặc dùng try/catch trong middleware và next(err) thủ công.

Failure mode 5: Fastify — setErrorHandler thiếu, response mặc định lộ chi tiết. Fastify tự bắt lỗi async, nhưng nếu không đăng ký setErrorHandler và error không phải instance của httpErrors, mặc định trả 500 với message của error. Trên môi trường prod, tránh lộ chi tiết implementation; luôn đăng ký setErrorHandler để chuẩn hóa payload lỗi và log theo request id.

Cách debug và monitor

Triệu chứng: request treo tới requestTimeout, không log access; process log có dòng UnhandledPromiseRejection; ở K8s, pod restart bất chợt sau khi có traffic lỗi DB. Cách xử lý:

Bắt unhandledRejection và uncaughtException ở tầng process. Theo Node docs process, đăng ký listener để log structured trước khi crash — nếu không, chỉ thấy stack thô trên stderr, khó phân biệt request nào gây ra. Log kèm err.stack, err.code, và nếu có context (AsyncLocalStorage request id) thì càng tốt.

  process.on('unhandledRejection', (reason) => {
    log.fatal({ err: reason }, 'unhandled_rejection')
    // để process exit tự nhiên theo --unhandled-rejections=throw của Node 15+
  })
  process.on('uncaughtException', (err) => {
    log.fatal({ err }, 'uncaught_exception')
    process.exit(1)
  })

Không "nuốt" bằng listener. Đừng dùng unhandledRejection handler để "cứu" process (chỉ log rồi return). Node docs nói rõ: kể từ Node 15, hành vi mặc định là crash — vì process ở trạng thái không xác định sau một lỗi không bắt. Log để observability, nhưng để process chết và để orchestrator restart.
Metric. Counter nodejs_unhandled_rejections_total (tên tự đặt) tăng khi listener chạy; alert khi rate khác 0. Kèm HTTP error rate theo route/status để biết endpoint nào là nguồn. Với Fastify, setErrorHandler là điểm tự nhiên để tăng counter theo err.code/err.statusCode.
CLI flag để chọn hành vi. node --unhandled-rejections=strict ép crash ngay lần đầu (kể cả trên Node < 15 nếu cần backport). warn cho môi trường dev nếu muốn tiếp tục chạy dù có lỗi. Ở production, để mặc định (throw) để phát hiện lỗi sớm.
ESLint rule. no-floating-promises (từ @typescript-eslint) ngăn commit code có Promise không await/.catch — chặn failure mode 2 và 4 ngay ở CI. Với JS thuần, promise/no-floating-promises từ eslint-plugin-promise làm việc tương tự.
Tracing. OpenTelemetry @opentelemetry/instrumentation-express và @opentelemetry/instrumentation-fastify (theo OpenTelemetry docs mục JavaScript instrumentation) tạo span cho từng middleware/handler. Khi async reject không được bắt, span kết thúc với status ERROR kèm exception attribute — trace hiện ra chính hàm ném lỗi mà không phải grep log.

Rule phòng ngừa: (1) mọi route/middleware async trong Express 4 phải qua asyncHandler hoặc import express-async-errors; (2) không fire-and-forget Promise trong handler mà không có .catch; (3) luôn có listener unhandledRejection để log structured; (4) bật ESLint no-floating-promises ở CI; (5) trong Fastify luôn đăng ký setErrorHandler để chuẩn hóa payload lỗi.

Tradeoff

Wrapper trong Express 4 rẻ về runtime (một closure và một .catch), nhưng đắt về kỷ luật: chỉ cần một route mới quên bọc là lại tái hiện failure mode 1. express-async-errors monkey-patch giúp DX, nhưng đổi lại là behavior không rõ ràng từ code — người đọc phải biết có import 'express-async-errors' ở đâu đó. Express 5 giải quyết ở tầng framework, giá là chi phí migrate (breaking changes ở path-to-regexp, req.query immutable, một số middleware cũ chưa tương thích).

Fastify auto-catch giảm code boilerplate và loại bỏ cả một class lỗi ở review, nhưng cần chú ý: mọi throw trong handler đều đi qua error handler — không có "throw để log rồi tiếp tục". Nếu muốn behavior khác (ví dụ retry trong cùng handler), phải try/catch thủ công. Ngoài ra setErrorHandler mặc định (khi không tự đăng ký) trả message error thô ra client — cần override ở production.

Rule of thumb: nếu vẫn ở Express 4, bọc asyncHandler cho mọi async route/middleware, coi đó là boilerplate cứng như import; bật ESLint no-floating-promises. Nếu bắt đầu service mới, chọn Fastify hoặc Express 5 để bỏ hẳn lớp lỗi này. Không dùng listener unhandledRejection để "cứu" process — chỉ log rồi để crash.

Câu hỏi phỏng vấn

Vì sao lỗi ném ra từ một async route handler trong Express 4 không tới error middleware, và cần làm gì để nó tới?

Express 4 bọc lời gọi handler bằng try/catch đồng bộ. Một hàm async không ném lỗi — nó return về một Promise. Đến khi Promise reject, control đã ra khỏi try/catch từ lâu, nên catch block không chạy và Express không gọi next(err). Reject rơi ra tầng process thành unhandledRejection; từ Node 15 mặc định --unhandled-rejections=throw, nghĩa là process crash. Cách sửa chuẩn là wrapper asyncHandler = (fn) => (req, res, next) => Promise.resolve(fn(req, res, next)).catch(next) — biến Promise reject thành next(err) để error middleware bắt. Có thể thay bằng express-async-errors (monkey-patch tự await) hoặc migrate lên Express 5 (native support). Điểm ăn điểm là gọi được ba thứ: cơ chế (try/catch đồng bộ không bắt được Promise reject), hậu quả production (một lỗi DB làm crash pod thay vì trả 500 JSON), và cách phòng thêm ngoài wrapper — listener unhandledRejection để log structured, ESLint no-floating-promises để chặn ở CI, và đối chiếu với Fastify — pipeline hook tự await handler nên không có class lỗi này ngay từ đầu.

Hands-on

Dựng hai server cạnh nhau, tái hiện async reject không bọc, xem process crash, rồi sửa. Toàn bộ chạy được với Node 18+.

Chuẩn bị:

mkdir async-route && cd async-route
npm init -y
npm pkg set type=module
npm i express fastify pino
npm i -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser

Tạo express-broken.mjs — bản Express 4 KHÔNG bọc:

import express from 'express'
import pino from 'pino'

const log = pino()
const app = express()

process.on('unhandledRejection', (reason) => {
  log.fatal({ err: reason }, 'unhandled_rejection')
})
process.on('uncaughtException', (err) => {
  log.fatal({ err }, 'uncaught_exception')
  process.exit(1)
})

// giả lập DB call reject
const fakeDbFind = async (id) => {
  if (id === 'bad') throw new Error('db_connection_refused')
  return { id, total: 100 }
}

// SAI: async handler không bọc, reject không tới error middleware
app.get('/orders/:id', async (req, res) => {
  const order = await fakeDbFind(req.params.id)
  res.json(order)
})

app.use((err, _req, res, _next) => {
  res.status(500).json({ error: 'internal' })
})

const server = app.listen(3001, () => log.info('express-broken :3001'))
server.requestTimeout = 5000

Tạo express-fixed.mjs — bản có wrapper:

import express from 'express'
import pino from 'pino'

const log = pino()
const app = express()

const asyncHandler = (fn) => (req, res, next) =>
  Promise.resolve(fn(req, res, next)).catch(next)

const fakeDbFind = async (id) => {
  if (id === 'bad') throw new Error('db_connection_refused')
  return { id, total: 100 }
}

app.get('/orders/:id', asyncHandler(async (req, res) => {
  const order = await fakeDbFind(req.params.id)
  res.json(order)
}))

app.use((err, req, res, _next) => {
  log.error({ err, url: req.url }, 'request_failed')
  res.status(500).json({ error: 'internal' })
})

app.listen(3002, () => log.info('express-fixed :3002'))

Tạo fastify-server.mjs — Fastify auto-catch:

import Fastify from 'fastify'

const app = Fastify({ logger: true })

const fakeDbFind = async (id) => {
  if (id === 'bad') throw new Error('db_connection_refused')
  return { id, total: 100 }
}

app.setErrorHandler((err, req, reply) => {
  req.log.error({ err }, 'request_failed')
  reply.status(err.statusCode ?? 500).send({ error: err.code ?? 'internal' })
})

app.get('/orders/:id', async (req) => {
  return fakeDbFind(req.params.id)   // reject sẽ được Fastify bắt tự động
})

await app.listen({ port: 3003 })

Chạy và quan sát:

# Terminal 1: server broken
node --unhandled-rejections=throw express-broken.mjs

# Terminal 2: gọi endpoint tốt và endpoint xấu
curl -s http://localhost:3001/orders/ok    # {"id":"ok","total":100}
curl -s http://localhost:3001/orders/bad   # request treo, sau đó server tự crash

# Quan sát Terminal 1: log fatal "unhandled_rejection" + process exit

Chạy express-fixed.mjs và fastify-server.mjs song song, lặp lại curl .../orders/bad:

node express-fixed.mjs &
node fastify-server.mjs &

curl -s -w "\n%{http_code}\n" http://localhost:3002/orders/bad
# -> {"error":"internal"} 500 -- error middleware chạy, process không crash

curl -s -w "\n%{http_code}\n" http://localhost:3003/orders/bad
# -> {"error":"internal"} 500 -- Fastify tự bắt qua setErrorHandler

Cuối cùng bật ESLint rule để chặn floating promise ở CI. Tạo .eslintrc.json:

{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"],
  "rules": {
    "@typescript-eslint/no-floating-promises": "error"
  }
}

Thêm một hàm fire-and-forget vào một file .ts (ví dụ audit.write(...) không await), chạy npx eslint . và xác nhận rule bắt được — đây là hàng rào cuối cùng ngăn failure mode 2/4 lọt vào main branch.

HTTP Server — Request Lifecycle

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:48 +0000

Request lifecycle: một HTTP request đi qua đâu, và vì sao "quên gọi next()" làm request treo cho tới khi socket timeout

Một request tới một Express hay Fastify server không phải là "gọi handler rồi trả về response". Nó là một chuỗi các bước theo thứ tự cố định: parse HTTP, chạy qua middleware/hook, match route, gọi handler, serialize, gửi response, đóng. Nếu bất kỳ bước nào không chuyển tiếp — Express không gọi next(), Fastify hook không reply.send() hay không return — request treo cho tới khi client hoặc server timeout đóng socket. Đây là loại lỗi không ném exception, không xuất hiện trong error log, chỉ hiện ra qua p99 latency phình lên và số socket ở trạng thái ESTABLISHED tăng dần. Hiểu chính xác lifecycle này là điều kiện tiên quyết để debug những request "biến mất" và để đặt middleware đúng thứ tự.

Cơ chế hoạt động

Bước dưới cùng giống nhau ở cả hai framework: Node core http.Server nhận TCP connection, parse HTTP request line + headers, phát event request với hai object IncomingMessage (req) và ServerResponse (res). Điểm khác nhau là những gì framework làm giữa lúc nhận request và lúc response ra khỏi socket.

Express dựng một chuỗi middleware qua Router. Mỗi lần app.use(fn) hay app.get(path, fn) được gọi, Express bọc fn vào một Layer với path regex (thông qua path-to-regexp) rồi push vào một stack. Khi request đến, Router.handle duyệt stack tuần tự: với mỗi layer, nếu path match, gọi fn(req, res, next). next() là closure trỏ vào layer kế tiếp; chỉ khi nó được gọi thì layer sau mới chạy. Error handler được nhận diện bằng arity — hàm 4 tham số (err, req, res, next) — và chỉ được duyệt tới khi next(err) được gọi:

import express from 'express'
const app = express()

app.use(express.json({ limit: '1mb' }))           // 1. parse body
app.use((req, _res, next) => {                    // 2. request id
  req.id = crypto.randomUUID()
  next()
})
app.use((req, _res, next) => {                    // 3. auth
  const token = req.headers.authorization
  if (!token) return next(new Error('unauth'))
  next()
})
app.get('/orders/:id', async (req, res, next) => { // 4. route handler
  try {
    const order = await db.orders.findById(req.params.id)
    if (!order) return res.status(404).json({ error: 'not_found' })
    res.json(order)
  } catch (err) { next(err) }                      // chuyển sang error handler
})
app.use((err, req, res, _next) => {               // 5. error handler (arity 4)
  res.status(500).json({ error: 'internal', id: req?.id })
})

Fastify thay chuỗi middleware phẳng bằng một pipeline hook có tên và thứ tự cố định, tài liệu ở Fastify docs mục "Lifecycle": onRequest → preParsing → preValidation → preHandler → handler → preSerialization → onSend → response gửi đi → onResponse. Nhánh lỗi rẽ qua onError. Route matching dùng find-my-way (radix trie) thay vì regex tuyến tính. Serialization dùng fast-json-stringify compile schema thành hàm serialize chuyên biệt, thay vì JSON.stringify chung:

import Fastify from 'fastify'
const app = Fastify({ logger: true })

app.addHook('onRequest', async (req) => {         // trước khi body được parse
  req.id = req.headers['x-request-id'] ?? crypto.randomUUID()
})
app.addHook('preHandler', async (req) => {        // sau parse+validate, trước handler
  if (!req.headers.authorization) throw app.httpErrors.unauthorized()
})

app.get('/orders/:id', {
  schema: {
    response: {
      200: { type: 'object', properties: { id: { type: 'string' }, total: { type: 'number' } } }
    }
  }
}, async (req) => {
  const order = await app.db.orders.findById(req.params.id)
  if (!order) throw app.httpErrors.notFound()
  return order                                    // preSerialization -> onSend -> socket
})

Điểm chung: cả hai chỉ tiến sang bước kế tiếp khi bước hiện tại "kết thúc". Ở Express, "kết thúc" nghĩa là next() hoặc gửi response. Ở Fastify async, "kết thúc" nghĩa là promise resolve/reject. Nếu không xảy ra sự kiện đó, pipeline đứng im.

Vấn đề gặp trong production

Failure mode 1: quên next() — request treo tới timeout. Middleware chạy xong phần logic nhưng không gọi next() và cũng không gửi response — chuỗi dừng lại giữa chừng:

// SAI: async middleware "trông có vẻ đủ" nhưng thiếu next()
app.use(async (req, _res) => {
  const user = await verifyToken(req.headers.authorization)
  req.user = user
  // quên next() — không có exception, không có log, request đứng im
})

Không có lỗi nào ném. Client thấy request đang chờ. Sau vài chục giây, hoặc keepAliveTimeout hoặc client-side timeout kết thúc, socket đóng ở trạng thái RST/FIN. Log của server không thấy gì vì không middleware nào tới bước gửi response. Cách sửa là luôn kết thúc middleware bằng một trong ba nhánh rõ ràng: gọi next(), next(err), hoặc gửi response.

// ĐÚNG: bọc async middleware để lỗi và tiếp nối đều chuyển tiếp đúng
const asyncMw = (fn) => (req, res, next) =>
  Promise.resolve(fn(req, res, next)).catch(next)

app.use(asyncMw(async (req, _res, next) => {
  req.user = await verifyToken(req.headers.authorization)
  next()
}))

Express 5 xử lý phần này gọn hơn: nếu handler là async, promise reject sẽ tự bị bắt và forward vào error chain. Trên Express 4 (vẫn đang chạy ở phần lớn service), phải tự bọc như trên.

Failure mode 2: sai thứ tự middleware. Middleware là stack có thứ tự — thứ tự app.use(...) chính là thứ tự chạy. Đặt error handler trước route sẽ khiến nó không bao giờ được gọi (vì next(err) đi xuôi chứ không lùi). Đặt logger sau body parser sẽ khiến logger không thấy được request nào bị reject ở tầng parse. Đặt auth sau route handler thì route đã chạy trước khi auth chặn:

// SAI: route đăng ký trước auth => endpoint mở toang
app.get('/admin/users', listUsers)
app.use(authMiddleware)

// ĐÚNG: middleware nào áp cho route nào phải nằm TRƯỚC route đó trong stack
app.use(authMiddleware)
app.get('/admin/users', listUsers)

Failure mode 3: gửi response hai lần — ERR_HTTP_HEADERS_SENT. Sau khi res.json() hay res.send() chạy, headers đã đi ra socket. Bất kỳ lần ghi tiếp nào đều ném lỗi này. Kịch bản thường gặp: một nhánh if sớm đã res.send, code phía sau vẫn tiếp tục và gọi res.send lần nữa vì thiếu return:

// SAI: thiếu return sau res.status(404).json(...)
app.get('/orders/:id', async (req, res, next) => {
  const order = await db.orders.findById(req.params.id)
  if (!order) res.status(404).json({ error: 'not_found' })  // không return
  res.json(order)   // chạy tiếp, ném ERR_HTTP_HEADERS_SENT + gửi payload sai
})

Sửa: luôn return res.json(...) hoặc dùng else. Trong Fastify, mô hình return payload từ handler tránh được lớp lỗi này vì reply được commit bởi framework một lần duy nhất.

Failure mode 4: body parser limit + slow client. express.json({ limit: '1mb' }) mặc định ném 413 Payload Too Large khi vượt limit, nhưng nếu không đặt req.setTimeout hoặc server.requestTimeout, một client chậm có thể giữ socket mở, upload nhỏ giọt và ăn RAM. Fastify có bodyLimit (mặc định ~1MB, theo Fastify docs) và tôn trọng server.requestTimeout của Node core. Với upload thực tế, đặt cả bodyLimit và một timeout dứt khoát ở tầng server.

Cách debug và monitor

Triệu chứng "request biến mất" cần được phân biệt với "request lỗi". Log tầng access chỉ ghi khi response gửi đi; nếu request treo giữa middleware, access log không có dòng nào. Bốn cách tiếp cận:

Log từng bước lifecycle. Ở Express, thêm một middleware đầu chuỗi ghi req.id, timestamp bắt đầu; và một hook cuối gắn vào res.on('finish') + res.on('close') để phân biệt response gửi thành công (finish) và socket đóng khi chưa xong (close mà res.writableEnded === false là request bị hủy giữa chừng). Ở Fastify, bật logger: true — nó dùng pino và tự log mỗi request + response với reqId, responseTime. Với các hook trung gian, dùng onRequest/onResponse để đo chênh lệch thời gian.
Timeout dứt khoát. Đặt server.requestTimeout và server.headersTimeout ở tầng http.Server (theo Node docs http.Server; requestTimeout có mặc định khác 0 từ Node 18). Không dựa vào client timeout — curl mặc định không timeout.
Tracing. OpenTelemetry có @opentelemetry/instrumentation-express và @opentelemetry/instrumentation-fastify (theo OpenTelemetry docs mục JavaScript instrumentation). Chúng bọc từng middleware/hook thành span con, nên khi request treo, trace hiện ra chính span đang mở — biết ngay middleware nào là thủ phạm mà không phải rải console.log.
Metric. Histogram HTTP request duration theo route + status (http.server.request.duration là tên theo OpenTelemetry semantic conventions cho HTTP). Alert khi p99 tăng đột biến hoặc khi số request không có response (không match cặp start/finish) khác 0. Kèm gauge số socket đang mở qua server.getConnections — nếu con số này leo lên trong khi RPS không tăng, có request đang giữ socket.

Rule phòng ngừa: (1) middleware phải luôn kết thúc rõ ràng — hoặc next(), hoặc gửi response, hoặc throw/next(err); (2) return res.send(...) chứ không viết res.send(...) không return; (3) mọi server production đều đặt requestTimeout và headersTimeout khớp với LB phía trước; (4) route đăng ký sau khi mọi middleware toàn cục đã app.use.

Tradeoff

Express linh hoạt vì middleware là hàm arbitrary — có thể chèn bất cứ gì vào bất cứ chỗ nào trong stack. Cái giá là không có ranh giới rõ giữa "trước parse" và "sau validate": một middleware Express về nguyên tắc chạy ở mọi thời điểm trước handler, người viết tự phải giữ thứ tự đúng. Không có schema-based serialization, nên serialize dùng JSON.stringify chung — chậm hơn khi payload lớn. Router dựa trên regex, chi phí tuyến tính theo số route được đăng ký.

Fastify chạy nhanh hơn ở workload JSON điển hình — theo benchmark repo fastify/benchmarks do maintainer Fastify duy trì, throughput trên các route JSON đơn giản cao hơn Express đáng kể (nhiều lần trên cùng phần cứng, cùng payload). Ba nguyên nhân, đều là quyết định thiết kế: (a) find-my-way radix trie router, tra route ở chi phí gần hằng số theo độ dài path chứ không theo số route; (b) fast-json-stringify compile schema thành hàm serialize chuyên biệt, tránh reflection và loại field không có trong schema; (c) pipeline hook cố định giúp Fastify pre-compile chuỗi call, không phải duyệt stack động mỗi request. Đổi lại: schema-based có nghĩa payload phải có schema (hoặc chấp nhận rơi về JSON.stringify chung); mô hình hook cố định khó "chèn ngang" hơn middleware phẳng của Express; ecosystem plugin nhỏ hơn.

Rule of thumb: chọn Express khi ưu tiên độ quen thuộc, plugin ecosystem rộng, hoặc middleware bên thứ ba không có bản Fastify. Chọn Fastify khi payload JSON là hot path, RPS cao, hoặc muốn schema validation + typed reply có sẵn. Đừng chọn Fastify chỉ vì "nhanh hơn" trên một service RPS thấp — chênh lệch throughput ở dưới vài trăm RPS không thấy được, còn chi phí học/refactor thì thấy ngay.

Câu hỏi phỏng vấn

Một HTTP request đi qua những bước nào trong một Express app, và điều gì xảy ra nếu một middleware quên gọi next()?

Node core http.Server parse HTTP request rồi phát event request với (req, res). Express đưa cặp này vào Router.handle, duyệt tuần tự stack các Layer đã đăng ký qua app.use/app.METHOD. Mỗi layer match path sẽ được gọi (req, res, next); chỉ khi next() được gọi mới sang layer tiếp theo. next(err) nhảy tới middleware error handler gần nhất (nhận diện bằng arity 4: err, req, res, next). Khi tới route handler, nó gửi response qua res.json/res.send; response ghi xong headers rồi body, event finish phát ra và socket có thể quay lại pool keep-alive. Nếu một middleware quên next() và cũng không gửi response, pipeline dừng lại: không có exception, không có log access, request treo cho tới khi server.requestTimeout/headersTimeout hoặc client-side timeout đóng socket. Điểm ăn điểm là gọi tên hậu quả production — p99 latency phình lên nhưng error log không thấy gì, số socket ESTABLISHED tăng dần — và cách phòng: bọc async middleware để reject tự forward qua next, luôn return res.send(...), đặt requestTimeout ở tầng http.Server khớp với LB, dùng OpenTelemetry instrumentation để trace phơi ra chính hook/middleware đang mở khi request treo.

Hands-on

Dựng hai server tối thiểu trong cùng repo và làm chúng vỡ theo đúng failure mode ở trên, rồi sửa.

Chuẩn bị:

mkdir req-lifecycle && cd req-lifecycle
npm init -y
npm pkg set type=module
npm i express fastify pino
npm i -D autocannon

Tạo express-server.mjs:

import express from 'express'
import crypto from 'node:crypto'

const app = express()
app.use(express.json({ limit: '1mb' }))

// LOG mỗi bước lifecycle
app.use((req, res, next) => {
  req.id = crypto.randomUUID()
  req._t = process.hrtime.bigint()
  console.log(JSON.stringify({ id: req.id, step: 'in', url: req.url }))
  res.on('finish', () => console.log(JSON.stringify({ id: req.id, step: 'finish' })))
  res.on('close',  () => {
    if (!res.writableEnded) console.log(JSON.stringify({ id: req.id, step: 'aborted' }))
  })
  next()
})

// Middleware CỐ Ý QUÊN next() — tái hiện request treo
app.use('/broken', (req, _res /*, next */) => {
  console.log(JSON.stringify({ id: req.id, step: 'broken-mw-entered' }))
  // không next(), không res.send => request treo
})

app.get('/ok', (req, res) => {
  res.json({ id: req.id, ok: true })
})

const server = app.listen(3001, () => console.log('express :3001'))
server.requestTimeout = 5000      // 5s: request treo sẽ bị cắt
server.headersTimeout = 6000

Tạo fastify-server.mjs:

import Fastify from 'fastify'

const app = Fastify({ logger: true, bodyLimit: 1_000_000 })

app.addHook('onRequest',   async (req) => { req.log.info({ step: 'onRequest' }) })
app.addHook('preHandler',  async (req) => { req.log.info({ step: 'preHandler' }) })
app.addHook('onResponse',  async (req, reply) => {
  req.log.info({ step: 'onResponse', ms: reply.elapsedTime })
})

app.get('/ok', {
  schema: { response: { 200: { type: 'object', properties: { ok: { type: 'boolean' } } } } }
}, async () => ({ ok: true }))

// Handler cố ý không return -> Fastify treo cho tới requestTimeout
app.get('/broken', async () => {
  await new Promise(() => {})  // pending mãi mãi
})

await app.listen({ port: 3002 })

Chạy song song hai server và quan sát:

node express-server.mjs &
node fastify-server.mjs &

# 1) request bình thường: thấy log các step in / finish
curl -s http://localhost:3001/ok
curl -s http://localhost:3002/ok

# 2) request treo: curl đợi cho tới khi server cắt tại requestTimeout=5s
time curl -sv http://localhost:3001/broken
time curl -sv http://localhost:3002/broken

# 3) bắn tải song song vào /ok trong lúc một request đang treo trên /broken —
#    quan sát /ok vẫn phản hồi bình thường (event loop không bị block,
#    chỉ có socket của /broken đang giữ)
npx autocannon -c 50 -d 10 http://localhost:3001/ok
npx autocannon -c 50 -d 10 http://localhost:3002/ok

Sau đó sửa /broken ở Express bằng cách thêm next() (hoặc gửi response), và ở Fastify bằng cách return {...} từ handler. Chạy lại time curl và xác nhận response trả về ngay, không còn phải chờ requestTimeout. Cuối cùng bật một OpenTelemetry SDK với @opentelemetry/instrumentation-express hoặc @opentelemetry/instrumentation-fastify (theo hướng dẫn ở OpenTelemetry docs), reproduce lại request treo và xem trace: span của middleware/hook đang treo hiện ra ở trạng thái chưa đóng — đây là cách khoanh vùng thủ phạm trong service thật mà không phải rải console.log.

End-to-end Design Walkthrough — Full System Design

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:44 +0000

Full system design walkthrough: vì sao quy trình 5 bước quan trọng hơn thuật ngữ, và cái bẫy nhảy thẳng vào deep-dive

Một buổi phỏng vấn system design 45–60 phút không đánh giá xem thí sinh biết bao nhiêu tên công nghệ, mà đánh giá xem thí sinh có xử lý được một bài toán mơ hồ theo một quy trình có kỷ luật hay không. Cùng đề "thiết kế URL shortener", người thất bại thường bắt đầu bằng "dùng Cassandra vì scale tốt" ngay ở phút thứ hai — chưa hỏi scale bao nhiêu, chưa biết read/write ratio, chưa đồng ý interface. Người pass đi theo một trình tự cứng: requirements → estimation → high-level → deep-dive → tradeoff. Cùng một đề, cùng thời lượng, nhưng người thứ hai dẫn dắt được interviewer thay vì bị dí. Bài này mô tả quy trình đó ở mức thực dụng, các thất bại thường gặp khi bỏ bước, và một hands-on end-to-end trên URL shortener để tự luyện.

Cơ chế hoạt động

Quy trình chuẩn được nhiều tài liệu tổng hợp (Alex Xu — System Design Interview vol.1; Donne Martin — system-design-primer; Kleppmann — Designing Data-Intensive Applications) đều có 4–5 bước gần như trùng nhau. Đây là khung 5 bước dùng thực tế trong phỏng vấn:

Requirements clarification (~5 phút). Chốt functional requirement (hệ thống làm gì — API nào, use case nào) và non-functional requirement (availability target, latency target, consistency yêu cầu, security, cost). Không đoán — hỏi lại interviewer. Output: 3–5 gạch đầu dòng functional + 3–5 gạch NFR + danh sách "out of scope" (analytics, billing, ...).
Back-of-the-envelope estimation (~5 phút). Tính DAU, QPS peak/avg, read:write ratio, storage growth theo năm, bandwidth. Không cần chính xác — cần đúng order of magnitude để quyết định "cần shard hay không", "cache có ý nghĩa không", "một node đủ hay phải scale ngang".
High-level design (~10–15 phút). Vẽ box diagram: client → LB → app tier → cache → primary datastore → async worker → object storage/CDN. Định nghĩa API (endpoint, request/response, status code) và data model (schema chính, index chính). Ở bước này chưa đi sâu vào từng box.
Deep-dive (~15–20 phút). Interviewer sẽ chỉ vào một box và hỏi "cái này scale thế nào?". Đây là nơi giải thích: sharding scheme (partition key nào, tại sao), replication (sync/async, quorum), cache strategy (cache-aside, write-through, TTL, invalidation), consistency model (read-your-write, eventual), bottleneck và cách xử lý.
Tradeoff & wrap-up (~5 phút). Nêu lựa chọn nào đánh đổi cái gì, cái gì có thể làm khác nếu NFR đổi (vd: nếu strong consistency là bắt buộc thì phải bỏ multi-region active-active), và các failure mode chính đã được xử lý (single AZ down, DB primary chết, cache miss storm).

Một mental checklist ngắn để không lạc:

[R] Functional API:      ...
[R] NFR (SLA, RPS, p99): ...
[R] Out of scope:        ...
[E] DAU / QPS:           ...
[E] Read:Write ratio:    ...
[E] Storage / year:      ...
[H] API contract:        POST /... GET /...
[H] Data model:          table(...), index(...)
[H] Diagram:             client -> LB -> app -> cache -> DB / queue -> worker
[D] Partition key:       ...
[D] Cache strategy:      ...
[D] Consistency:         ...
[D] Bottleneck & fix:    ...
[T] What breaks:         ...
[T] What we would change:...

Điểm quan trọng: các bước này không phải tuyến tính cứng. Deep-dive có thể phát hiện estimation sai → quay lại estimation. Nhưng bỏ hẳn một bước — điển hình là bỏ estimation và requirements — thì phần sau mất neo, mọi lựa chọn thành opinion không có căn cứ.

Vấn đề gặp trong production

Đây là "production" của bài phỏng vấn — thất bại thật sự lặp lại ở loạt vòng System Design mà nhiều tài liệu (Alex Xu, interviewing.io blog, Grokking SDI) đã tổng kết:

Failure mode 1: nhảy vào chi tiết không có cấu trúc. Đề "design Twitter", ngay phút thứ 3 đã vẽ Kafka + Cassandra + Redis + Elasticsearch. Interviewer hỏi "read:write ratio là bao nhiêu?" → không biết. Hỏi "vì sao Cassandra chứ không Postgres?" → không trả lời được vì chưa biết access pattern. Đây là dạng thất bại phổ biến nhất: chọn công nghệ trước khi có yêu cầu.

Sai:

"Sẽ dùng Cassandra vì scale tốt, Kafka làm message bus, Redis cache,
 Elasticsearch cho search, Nginx load balancer..."
(đã 5 phút trôi qua, chưa có 1 dòng requirement, chưa có API, chưa có schema)

Đúng — bắt đầu ngược lại:

"Trước khi chọn stack, cần rõ vài thứ:
 - System hỗ trợ post text/media hay chỉ text?
 - Timeline home feed là chronological hay ranked?
 - Read heavy hay write heavy? Order of magnitude DAU?
 - Latency target cho feed? p99 dưới 200ms?
 - Cần strong consistency cho counter không, hay eventual ok?"

Sau khi có câu trả lời mới sang estimation, rồi high-level, rồi mới nói tới Kafka/Cassandra — và lúc đó mỗi lựa chọn có lý do gắn với requirement cụ thể.

Failure mode 2: bỏ back-of-envelope estimation. Không có ước lượng thì mọi câu "cần shard không", "một DB đủ không", "cache có đáng không" đều thành đoán mò. Tệ hơn: chọn kiến trúc quá phức tạp cho tải nhỏ (over-engineer) hoặc quá đơn giản cho tải lớn (miss bottleneck). Ví dụ với URL shortener: nếu không tính ra "read gấp nhiều lần write" (thường được cite ở tỉ lệ order-of-magnitude 100:1 trong các tài liệu SDI), sẽ không thấy vì sao cache là quyết định trung tâm chứ không phải phụ. Cách sửa: sau khi có DAU và QPS, luôn viết ra một dòng "read RPS ≈ ..., write RPS ≈ ..., ratio ≈ ..." và một dòng "storage tăng ≈ ... / năm" trước khi vẽ box.

Failure mode 3: thiết kế thiếu trọng tâm — bỏ sót thành phần bắt buộc. Vẽ xong high-level mà thiếu load balancer, thiếu cache tier, thiếu async worker cho việc nặng, thiếu CDN cho static, thiếu health check / retry / timeout — đến deep-dive bị hỏi "làm sao xử lý spike?" thì đứng hình. Rule để không sót: mỗi box phải trả lời được ba câu — "nó scale thế nào (horizontal/vertical)", "nó fail thì sao (replica, failover)", "nó bị chậm thì có gì đỡ (cache, queue, backpressure)". Nếu một box không trả lời được cả ba, đó là chỗ interviewer sẽ đâm vào.

Failure mode 4: deep-dive không có ưu tiên. Interviewer nói "đi sâu vào phần thấy thú vị nhất" — thí sinh chọn phần dễ (thường là tầng app stateless) thay vì phần khó (sharding datastore, hot key, cache invalidation). Cách xử lý: chủ động chỉ ra 2–3 chỗ thật sự khó của bài rồi chọn một để đi sâu — điều này cho thấy đã nhận diện được risk area, khác hẳn với đi sâu chỗ an toàn cho có.

Failure mode 5: quản lý thời gian sai — hết giờ ở high-level. Dành 20 phút cho requirements + high-level, còn 5 phút cho deep-dive và không có wrap-up. Interviewer chấm điểm deep-dive nặng nhất nên phần yếu nhất lại là phần nặng điểm nhất. Rule cứng: đặt time-box mềm cho mỗi bước và tự nhắc mình sang bước tiếp — nếu chưa xong requirement sau 7 phút thì bỏ những thứ còn mơ hồ vào "assumption" và đi tiếp.

Failure mode 6: không nêu tradeoff, chỉ nêu lựa chọn. Nói "dùng Postgres" không đủ; phải nói "chọn Postgres vì write pattern có transaction, chấp nhận scale ngang khó hơn Cassandra — nếu QPS write vượt X thì sẽ shard theo user_id hoặc chuyển sang một wide-column store". Mỗi lựa chọn kèm điều kiện đảo. Đây là cách interviewer phân biệt senior với người học thuộc bài.

Cách debug và monitor

"Debug" ở đây là tự kiểm tra buổi phỏng vấn khi đang chạy — không có monitor tự động cho câu trả lời miệng, nhưng có heuristic thay thế.

Triệu chứng đang lạc bước:

Đã 10 phút mà chưa vẽ box đầu tiên → mắc kẹt ở requirement, cần bỏ chi tiết chưa rõ vào "assumption: ..." và đi tiếp.
Interviewer hỏi cùng một câu hai lần theo cách khác → dấu hiệu câu trả lời chưa chạm; dừng lại xác nhận lại câu hỏi thay vì nói tiếp.
Đã vẽ 6 box mà chưa có API/schema nào → high-level thiếu "mặt phẳng dữ liệu", quay lại định nghĩa API và data model trước khi thêm box.
Không có con số nào trong phần deep-dive (không QPS, không kích thước row, không cache hit ratio giả định) → deep-dive đang là opinion; thêm một estimation cụ thể.

Checklist "monitor" trước khi kết thúc — dùng như post-flight check:

[ ] Đã hỏi ít nhất 3 câu clarify requirement chưa?
[ ] Có 1 dòng QPS + 1 dòng storage growth + 1 dòng ratio chưa?
[ ] Có API contract (method, path, request, response) chưa?
[ ] Có schema chính (bảng, primary key, index) chưa?
[ ] Có LB + cache + primary store + async layer trên diagram chưa?
[ ] Đã nêu partition key và tại sao chưa?
[ ] Đã nêu ít nhất 2 failure mode và cách xử lý chưa?
[ ] Đã nêu ít nhất 1 tradeoff kèm điều kiện đảo chưa?

Rule phòng ngừa: luyện quy trình bằng cách viết ra khung 5 bước ở đầu tờ giấy nháp (hoặc góc whiteboard) trước khi nghe đề — buộc bản thân đi qua tuần tự, không cho phép nhảy. Sau vài lần lặp, quy trình trở thành reflex, không phải checklist phải nhớ.

Tradeoff

Quy trình có cấu trúc bao quát được toàn bộ bề mặt bài toán, giảm rủi ro bỏ sót và giúp interviewer chấm dễ (vì họ đã có rubric theo bước) — đổi lại nó cần luyện tập nhiều buổi để không trở thành đọc kịch bản cứng nhắc. Đi quá cứng theo bước dễ mất tự nhiên: chuyển từ "estimation" sang "high-level" mà bỏ qua manh mối interviewer vừa gợi ý là mất điểm giao tiếp; ngược lại đi quá tự do thì thiếu một bước nào đó, mất điểm coverage. Time-box quá chặt thì không kịp deep-dive; quá lỏng thì hết giờ ở requirement. Chọn công nghệ sớm (trước estimation) giúp câu chuyện có "hook" nhưng dễ bị hỏi ngược "tại sao đúng cái đó?" và không trả lời được; chọn muộn (sau deep-dive) an toàn hơn nhưng câu chuyện lan man.

Rule of thumb: đi đúng 5 bước theo thứ tự, nhưng time-box mềm — nếu một bước tràn quá 30% thời lượng dự kiến, chốt assumption và đi tiếp; luôn kết thúc bằng ít nhất một tradeoff kèm điều kiện đảo. Trong khoảng 10 buổi mock đầu tiên tuân thủ khung này chặt để tạo reflex; sau đó nới lỏng theo tình huống, giữ 5 mốc bắt buộc (requirement, estimation, API/schema, một deep-dive có số, một tradeoff).

Câu hỏi phỏng vấn

Quy trình thiết kế hệ thống trong một buổi phỏng vấn System Design gồm những bước nào, và tại sao thứ tự đó lại quan trọng?

Năm bước theo thứ tự: requirements (functional + non-functional + out-of-scope, hỏi lại interviewer để chốt), back-of-the-envelope estimation (DAU, QPS đọc/ghi, storage growth, ratio đọc/ghi — đủ order of magnitude để quyết định shard/cache), high-level design (API contract, data model chính, box diagram với LB + app + cache + DB + async worker), deep-dive (partition key, replication, consistency model, cache strategy và invalidation, bottleneck cụ thể), và tradeoff + wrap-up (mỗi lựa chọn kèm điều kiện đảo, failure mode chính đã cover). Thứ tự quan trọng vì mỗi bước là input cho bước sau: không có requirement thì không biết estimate cái gì; không có estimation thì mọi lựa chọn công nghệ ở high-level đều là opinion; không có high-level ổn thì deep-dive lạc chỗ; không có tradeoff thì interviewer không phân biệt được senior với người học thuộc bài. Điểm ăn điểm là gọi tên hai failure mode production của chính quy trình phỏng vấn: (1) nhảy thẳng vào chi tiết công nghệ (Kafka/Cassandra/Redis) trước khi có requirement — mọi câu "tại sao chọn cái này?" đều đứng hình; (2) thiết kế thiếu trọng tâm — bỏ sót load balancer/cache/async worker hoặc không nêu partition key ở deep-dive; cách xử lý là bám khung 5 bước với time-box mềm, luôn có ít nhất một con số ở deep-dive, và mỗi lựa chọn kèm điều kiện đảo.

Hands-on

Bài tập: thiết kế end-to-end một URL shortener theo đúng 5 bước, rồi dựng phiên bản tối thiểu bằng Docker để tự bắn tải và quan sát bottleneck xuất hiện ở đúng chỗ mà phần deep-dive đã dự đoán.

Bước 1 — Requirements (viết ra trước khi code):

Functional:
  - POST /shorten { url } -> { short }
  - GET  /:short          -> 301 -> original URL
  - (optional) custom alias
Non-functional:
  - Read heavy (click gấp nhiều lần tạo mới) — ratio order-of-magnitude 100:1
  - p99 redirect < 100ms
  - Availability cao (redirect là hot path)
  - Short code không đoán được
Out of scope:
  - Analytics chi tiết, billing, user auth

Bước 2 — Estimation (qualitative, đủ để quyết định):

Giả sử vài trăm triệu URL mới / năm  -> vài GB row data / tháng (thân URL + short)
Read RPS peak lớn hơn write RPS ~100 lần  -> cache là quyết định trung tâm
Short code 7 ký tự base62 -> ~62^7 ≈ hơn 3 nghìn tỉ tổ hợp — dư

Bước 3 — High-level design + API + schema:

client -> nginx (LB, TLS) -> app (stateless) -> Redis (cache) -> Postgres (primary)
                                              -> Postgres write path (POST /shorten)

Schema:

CREATE TABLE urls (
  short       TEXT PRIMARY KEY,
  long_url    TEXT NOT NULL,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

Bước 4 — Deep-dive (viết ra trước khi dựng):

Partition key: short (hash-shard nếu vượt 1 node)
Cache: cache-aside, key = short, TTL vài giờ, invalidate khi update
Hot key: một short viral -> Redis single key nóng, cần local in-process cache 1s TTL
ID generation: base62 của counter tăng dần (Snowflake-like) hoặc random 7-char + retry on conflict
Consistency: eventual — cache stale vài giây chấp nhận được

Bước 5 — Dựng phiên bản tối thiểu để verify deep-dive đúng.

Tạo thư mục lab và service Node tối giản (server.js):

const http = require("http");
const { Client } = require("pg");
const Redis = require("ioredis");
const crypto = require("crypto");

const pg = new Client({ connectionString: process.env.PG_URL });
const redis = new Redis(process.env.REDIS_URL);
const USE_CACHE = process.env.USE_CACHE === "1";

function shortCode() {
  return crypto.randomBytes(5).toString("base64url").slice(0, 7);
}

async function main() {
  await pg.connect();
  await pg.query(
    "CREATE TABLE IF NOT EXISTS urls(short TEXT PRIMARY KEY," +
    " long_url TEXT NOT NULL," +
    " created_at TIMESTAMPTZ NOT NULL DEFAULT now())"
  );

  http.createServer(async (req, res) => {
    try {
      if (req.method === "POST" && req.url === "/shorten") {
        let body = ""; for await (const c of req) body += c;
        const { url } = JSON.parse(body || "{}");
        const short = shortCode();
        await pg.query(
          "INSERT INTO urls(short,long_url) VALUES($1,$2)",
          [short, url]
        );
        res.writeHead(200, { "content-type": "application/json" });
        res.end(JSON.stringify({ short }));
      } else if (req.method === "GET" && req.url.length > 1) {
        const short = req.url.slice(1);
        let long;
        if (USE_CACHE) long = await redis.get("u:" + short);
        if (!long) {
          const r = await pg.query(
            "SELECT long_url FROM urls WHERE short=$1",
            [short]
          );
          if (!r.rows[0]) { res.writeHead(404).end(); return; }
          long = r.rows[0].long_url;
          if (USE_CACHE) await redis.set("u:" + short, long, "EX", 3600);
        }
        res.writeHead(301, { location: long }).end();
      } else {
        res.writeHead(404).end();
      }
    } catch (e) { res.writeHead(500).end(e.message); }
  }).listen(3000);
}
main();

package.json:

{ "name": "url-lab", "dependencies": { "pg": "^8", "ioredis": "^5" } }

Dockerfile:

FROM node:20-alpine
WORKDIR /app
COPY package.json server.js ./
RUN npm install --omit=dev
CMD ["node", "server.js"]

docker-compose.yml:

services:
  pg:
    image: postgres:16-alpine
    environment: { POSTGRES_PASSWORD: pw, POSTGRES_DB: urls }
    ports: ["5432:5432"]
  redis:
    image: redis:7-alpine
    ports: ["6379:6379"]
  app:
    build: .
    environment:
      PG_URL: postgres://postgres:pw@pg:5432/urls
      REDIS_URL: redis://redis:6379
      USE_CACHE: "0"
    depends_on: [pg, redis]
    ports: ["3000:3000"]

Dựng cụm và tạo một URL để lấy short code:

mkdir -p url-lab && cd url-lab
# lưu 4 file trên vào thư mục này
docker compose up -d --build

SHORT=$(curl -s -X POST localhost:3000/shorten \
  -H "content-type: application/json" \
  -d '{"url":"https://example.com/very/long/path"}' \
  | sed 's/.*"short":"\([^"]*\)".*/\1/')
echo "short=$SHORT"
curl -sI "localhost:3000/$SHORT" | head -2

Bắn tải vào redirect (read hot path), CHƯA bật cache:

# macOS: brew install wrk ; Debian/Ubuntu: sudo apt-get install wrk
wrk -t4 -c100 -d20s "http://localhost:3000/$SHORT"
# ghi lại Requests/sec và Latency p99

Bật cache và đo lại:

# sửa USE_CACHE trong docker-compose.yml thành "1"
docker compose up -d app
wrk -t4 -c100 -d20s "http://localhost:3000/$SHORT"
# kỳ vọng: RPS tăng nhiều lần, p99 giảm rõ; Postgres CPU giảm sâu

Verify Postgres đã hết là bottleneck khi có cache:

docker compose exec pg psql -U postgres -d urls -c \
  "SELECT query, calls, mean_exec_time FROM pg_stat_statements ORDER BY calls DESC LIMIT 5;"
# nếu chưa có extension:
#   docker compose exec pg psql -U postgres -c "CREATE EXTENSION pg_stat_statements"
# và thêm shared_preload_libraries='pg_stat_statements' vào postgresql.conf rồi restart

Tái hiện hot-key: chọn 1 short code duy nhất và bắn wrk với nhiều kết nối vào chính key đó — Redis single-key sẽ trở thành bottleneck (một shard, một key). Thêm một tầng in-process LRU cache 1s TTL trong server.js và đo lại — RPS lại nhảy vì phần lớn request không còn ra tới Redis. Đây chính là hot-key mitigation mà phần deep-dive đã dự đoán.

Cuối cùng, viết một trang one-pager tóm gọn: 5 bước, mỗi bước 3–5 dòng, khớp với những gì lab vừa verify. Đây là artifact mang vào phỏng vấn thật — chỉ khác đề, khung không đổi.

Idempotency — Safe Retry

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:41 +0000

Safe retry: idempotency key để retry một request không biến thành hai lần charge

Trong hệ phân tán, retry là mặc định — client, gateway, load balancer, queue consumer đều retry khi timeout hoặc lỗi tạm thời. Vấn đề là nhiều thao tác quan trọng không idempotent tự nhiên: một request POST /charges gửi hai lần thì trừ tiền khách hai lần, một message OrderCreated xử lý hai lần thì ship hai đơn. Idempotency key là cơ chế để server nhận diện "cùng một intent" giữa các lần retry và chỉ thực hiện side effect một lần, trong khi vẫn trả về response giống hệt cho mọi lần gọi lặp — về mặt hiệu ứng thấy được từ bên ngoài, đây là cái người ta hay gọi là "exactly-once effect" (dù ở tầng transport vẫn là at-least-once).

Cơ chế hoạt động

Client sinh một identifier duy nhất cho mỗi thao tác (thường là UUIDv4) và đính kèm request — quy ước phổ biến là HTTP header Idempotency-Key (Stripe API dùng đúng tên này, và IETF có draft draft-ietf-httpapi-idempotency-key-header chuẩn hoá cùng tên header). Server dùng key làm identity của thao tác trong một cửa sổ TTL:

Nhận request với key K.
Tra K trong idempotency store. Nếu tồn tại và request cũ ở trạng thái terminal (đã có response), trả lại response đã lưu — không chạy lại business logic.
Nếu tồn tại nhưng đang in-flight, trả 409 Conflict (hoặc chờ, tuỳ contract).
Nếu chưa tồn tại, INSERT bản ghi với unique constraint trên key, chạy business logic, persist response, commit.

Điểm cốt lõi là bước insert + bước business logic + bước lưu response phải nằm trong cùng một transaction boundary — hoặc chí ít, phải có cơ chế đảm bảo không có window mà một retry khác nhìn thấy "chưa có key" trong lúc lần đầu vẫn đang chạy dở.

CREATE TABLE idempotency_keys (
  key           TEXT        NOT NULL,
  user_id       BIGINT      NOT NULL,
  request_hash  TEXT        NOT NULL,          -- fingerprint payload
  status        TEXT        NOT NULL,          -- in_flight | succeeded | failed
  response_code INT,
  response_body JSONB,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  locked_until  TIMESTAMPTZ,
  PRIMARY KEY (user_id, key)
);
CREATE INDEX ON idempotency_keys (created_at);  -- để TTL sweeper dùng

// Express handler cho POST /charges
app.post('/charges', async (req, res) => {
  const key = req.header('Idempotency-Key')
  if (!key) return res.status(400).json({ error: 'missing Idempotency-Key' })

  const userId = req.auth.userId
  const bodyHash = sha256(canonicalize(req.body))

  const client = await pool.connect()
  try {
    await client.query('BEGIN')

    // 1. Cố gắng chiếm key. Unique constraint ép serialize retry cùng key.
    const ins = await client.query(
      `INSERT INTO idempotency_keys (user_id, key, request_hash, status, locked_until)
       VALUES ($1, $2, $3, 'in_flight', now() + interval '30 seconds')
       ON CONFLICT (user_id, key) DO NOTHING
       RETURNING key`,
      [userId, key, bodyHash],
    )

    if (ins.rowCount === 0) {
      // 2. Key đã tồn tại — đọc bản cũ.
      const { rows } = await client.query(
        `SELECT status, request_hash, response_code, response_body
         FROM idempotency_keys WHERE user_id=$1 AND key=$2 FOR UPDATE`,
        [userId, key],
      )
      const row = rows[0]
      if (row.request_hash !== bodyHash) {
        await client.query('ROLLBACK')
        return res.status(422).json({ error: 'idempotency key reused with different payload' })
      }
      if (row.status === 'in_flight') {
        await client.query('ROLLBACK')
        return res.status(409).json({ error: 'request in progress' })
      }
      await client.query('COMMIT')
      return res.status(row.response_code).json(row.response_body)
    }

    // 3. Lần đầu — chạy business logic trong cùng transaction.
    const charge = await createCharge(client, userId, req.body)  // dùng chung client

    await client.query(
      `UPDATE idempotency_keys
       SET status='succeeded', response_code=$3, response_body=$4
       WHERE user_id=$1 AND key=$2`,
      [userId, key, 200, charge],
    )
    await client.query('COMMIT')
    return res.status(200).json(charge)
  } catch (err) {
    await client.query('ROLLBACK')
    throw err
  } finally {
    client.release()
  }
})

Với message queue (Kafka, SQS, RabbitMQ), pattern giống hệt: dedup theo một business key (order id, payment intent id) trong một dedup store — Kafka producer còn có enable.idempotence=true để bản thân producer không ghi trùng vào broker, nhưng đó là idempotency ở tầng transport, không thay được dedup ở tầng consumer.

Vấn đề gặp trong production

Failure mode 1: race condition với hai retry song song cùng key. Không phải retry nào cũng tuần tự — khi client timeout ở lần 1 và bắn lại lần 2, request 1 có thể vẫn đang chạy dở trên server khác. Nếu handler chỉ làm "SELECT xem key có chưa, nếu chưa thì INSERT và chạy", hai request đều thấy chưa có key và cùng chạy — double charge:

// SAI: check-then-act không atomic
const existing = await db.query('SELECT * FROM idempotency_keys WHERE key=$1', [key])
if (existing.rowCount === 0) {
  const charge = await stripe.charges.create(...)  // hai request cùng vào đây
  await db.query('INSERT INTO idempotency_keys ...', [key, charge])
}

Fix là để database tự serialize bằng unique constraint (INSERT ... ON CONFLICT DO NOTHING như snippet ở trên) hoặc một distributed lock (Redis SET NX PX, DynamoDB conditional write). Cái duy nhất an toàn là một atomic op quyết định "ai là người thắng slot key này".

Failure mode 2: cache response của lỗi non-terminal. Nếu server lưu response cho cả các lỗi tạm thời (503, timeout upstream), lần retry sau sẽ nhận lại lỗi thay vì được chạy lại thật. Ngược lại, nếu quên lưu response khi request đã hoàn tất, retry sẽ chạy business logic lại. Nguyên tắc: chỉ persist response khi thao tác đạt trạng thái terminal (đã charge xong hoặc đã reject bằng business rule cứng như "thẻ hết hạn"). Với lỗi hạ tầng, xoá bản ghi key (hoặc để status failed_retryable) và cho retry.

Failure mode 3: key scoping quá rộng. Đưa Idempotency-Key làm primary key toàn hệ thống nghĩa là một user có thể (vô tình hoặc cố ý) đâm vào key của user khác. Ngoài lỗ hổng bảo mật, còn có bug thật: một client library sinh key kém entropy (dùng timestamp giây) sẽ va chạm. Luôn scope theo (tenant/user_id, key) như trong schema trên.

Failure mode 4: server sinh key thay vì client. Nếu server tự sinh key khi thấy request thiếu header, mỗi lần retry sẽ có key mới và mất luôn ý nghĩa dedup. Key phải do client sinh trước khi bắn request, và giữ nguyên qua mọi lần retry của cùng intent — thường là sinh ngay khi user bấm nút "Pay", lưu trong memory/localStorage, retry cùng key cho tới khi có response terminal.

Failure mode 5: side effect ngoài transaction. Business logic có thể chạm hệ ngoài không rollback được (gửi email, gọi payment gateway ngoài, publish event Kafka). Nếu commit idempotency row thành công nhưng crash trước khi gửi email, retry sẽ thấy key succeeded và bỏ qua email — dropped. Nếu gửi email xong rồi crash trước khi commit row, retry sẽ gửi email lần hai. Cách xử lý chuẩn là transactional outbox: ghi event vào bảng outbox trong cùng transaction với idempotency row, một relay riêng đọc outbox và publish với retry idempotent ở phía downstream. Với payment gateway ngoài, forward luôn Idempotency-Key xuống (Stripe, Adyen, Braintree đều accept) để chuỗi idempotent xuyên tầng.

Failure mode 6: TTL cắt trước khi client hết retry. Idempotency store phải có TTL (không giữ mãi), nhưng nếu TTL ngắn hơn window client retry (mobile client có thể retry sau vài giờ khi có mạng lại), retry rơi vào "key không còn" và chạy lại. Stripe docs nêu retention khoảng một ngày cho key — chọn TTL đủ dài so với retry policy dài nhất của client hợp lệ, không đặt bằng vài phút.

Cách debug và monitor

Triệu chứng ngoài production của một hệ idempotency hỏng thường là duplicate charge / duplicate order report từ support, không phải error log — vì mỗi request lẻ đều 200 OK. Vì vậy phải chủ động đo:

Duplicate rate metric: tỉ lệ request mà idempotency lookup match key có sẵn / tổng số request có key. Rate quá thấp (gần 0) nghĩa là client không retry, hoặc client sinh key mới mỗi lần — dedup không có tác dụng. Rate quá cao đột biến là dấu hiệu retry storm (thường do client timeout config quá ngắn so với p99 server).
In-flight collision rate: số lần trả 409 do key đang chạy. Đột biến ở đây thường trùng với latency spike phía dependency (payment gateway chậm khiến client retry trong lúc server chưa xong).
Payload mismatch rate: số lần retry với cùng key nhưng request_hash khác. Thường lộ bug client — user sửa amount rồi retry với key cũ.
Response header đánh dấu replay: nhiều API (Stripe là ví dụ) trả một header đánh dấu request được replay từ store thay vì chạy mới. Log header này ở client side để phân biệt "server thực sự chạy" và "server chỉ trả lại cache".

Về công cụ: với Postgres store, pg_stat_user_tables xem hot key trên bảng idempotency_keys, pg_locks khi nghi có contention; với DynamoDB store (AWS Lambda Powertools idempotency module dùng đúng pattern này), CloudWatch metric ConditionalCheckFailedRequests bắn khi hai retry đâm vào cùng key — chính là dấu hiệu dedup đang hoạt động, không phải lỗi.

Rule phòng ngừa cứng: (1) mọi endpoint có side effect ngoài (charge, ship, send) đều bắt buộc Idempotency-Key, reject 400 nếu thiếu; (2) key phải scope theo tenant; (3) TTL của store lớn hơn retry window dài nhất của client cộng biên an toàn; (4) mọi tích hợp với gateway ngoài forward key xuống downstream.

Tradeoff

Idempotency an toàn cho retry nhưng phải trả bằng state: một bảng/DynamoDB store lớn dần theo QPS nhân với TTL, một extra write mỗi request, và độ phức tạp trong transaction boundary. Với endpoint không có side effect (GET, read query), thêm idempotency chỉ tốn tài nguyên vô ích — HTTP đã định nghĩa GET là idempotent theo spec, retry an toàn sẵn.

Có hai điểm đánh đổi tinh tế hơn. Thứ nhất, strict dedup và conflict tolerance: nếu chọn trả 409 khi request đang in-flight, client phải biết cách backoff và thử lại — nhiều client library không xử lý 409 khéo, sinh ra retry loop. Chọn "block chờ" thay vì 409 thì đơn giản cho client nhưng chiếm connection của server lâu hơn. Thứ hai, key granularity: key hẹp (mỗi request unique) an toàn nhưng dedup không dùng lại được; key rộng (theo business id như order_id) tận dụng dedup tốt hơn nhưng phải chắc business id không được tái sử dụng.

Rule of thumb: bất cứ endpoint nào tạo/charge/send/publish với side effect thấy được từ ngoài, mặc định coi là phải idempotent, và bắt buộc key do client sinh, scope theo tenant, TTL lớn hơn retry window; endpoint read-only thì để nguyên vì HTTP method đã đảm bảo semantics.

Câu hỏi phỏng vấn

Thiết kế một payment endpoint idempotent để client retry không tạo charge trùng. Nêu cả cơ chế và các cách nó vẫn có thể vỡ.

Client sinh UUIDv4 cho mỗi intent "bấm nút Pay" và gửi qua header Idempotency-Key, giữ nguyên key qua mọi lần retry cho tới khi có response terminal. Server có một bảng idempotency_keys với primary key (user_id, key), unique constraint để hai retry song song không cùng insert được. Handler INSERT ... ON CONFLICT DO NOTHING trong một transaction, nếu insert được thì chạy business logic (tạo charge, gọi payment gateway — forward luôn key xuống gateway để dedup xuyên tầng) và update row với response terminal trong cùng transaction. Nếu conflict, đọc row cũ, so request_hash để chống reuse key với payload khác, rồi trả lại response cũ nếu đã terminal hoặc 409 nếu đang in-flight. TTL của bảng phải lớn hơn retry window dài nhất của client hợp lệ. Điểm ăn điểm là gọi tên các failure mode: race condition khi check-then-act không atomic (phải dựa unique constraint hoặc distributed lock, không phải SELECT rồi INSERT); side effect ngoài transaction (email, publish event) phải đi qua transactional outbox chứ không gọi trực tiếp trong handler; key phải do client sinh chứ không phải server (không thì retry sinh key mới, mất dedup); và phải monitor duplicate rate cùng conditional-check-failed để biết dedup có thực sự hoạt động, vì hệ hỏng thường không log error mà chỉ lộ ra ở duplicate charge report từ support.

Hands-on

Dựng lại toàn bộ chain và ép nó vỡ, rồi sửa. Chạy trên máy local với Docker.

Bước 1 — Postgres và schema:

docker run -d --name idem-pg -e POSTGRES_PASSWORD=pw -p 5432:5432 postgres:16
sleep 3
docker exec -i idem-pg psql -U postgres <<'SQL'
CREATE TABLE idempotency_keys (
  key TEXT NOT NULL,
  user_id BIGINT NOT NULL,
  request_hash TEXT NOT NULL,
  status TEXT NOT NULL,
  response_code INT,
  response_body JSONB,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (user_id, key)
);
CREATE TABLE charges (
  id BIGSERIAL PRIMARY KEY,
  user_id BIGINT NOT NULL,
  amount_cents INT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
SQL

Bước 2 — server Node dùng đúng handler ở phần "Cơ chế hoạt động" phía trên (copy khối app.post('/charges', ...), bọc quanh bằng express() + pg.Pool nối tới localhost:5432, thêm sha256 bằng crypto.createHash('sha256')), rồi node server.js.

Bước 3 — Test A, cùng key gửi 5 lần chỉ tạo 1 charge:

KEY=$(uuidgen)
for i in 1 2 3 4 5; do
  curl -s -X POST localhost:3000/charges \
    -H "Content-Type: application/json" \
    -H "Idempotency-Key: $KEY" \
    -d '{"amount_cents": 1000}'
  echo
done
docker exec -i idem-pg psql -U postgres -c "SELECT count(*) FROM charges;"
# expected: count = 1

Bước 4 — Test B, race condition song song cùng key:

KEY=$(uuidgen)
for i in 1 2 3 4 5 6 7 8; do
  curl -s -X POST localhost:3000/charges \
    -H "Content-Type: application/json" \
    -H "Idempotency-Key: $KEY" \
    -d '{"amount_cents": 2000}' &
done
wait
docker exec -i idem-pg psql -U postgres -c "SELECT count(*) FROM charges WHERE amount_cents=2000;"
# expected: 1 charge; 7 request kia trả 409 in-flight hoặc 200 replay

Bước 5 — Test C, payload mismatch reuse key:

KEY=$(uuidgen)
curl -s -X POST localhost:3000/charges -H "Idempotency-Key: $KEY" \
  -H "Content-Type: application/json" -d '{"amount_cents": 500}'
echo
curl -s -X POST localhost:3000/charges -H "Idempotency-Key: $KEY" \
  -H "Content-Type: application/json" -d '{"amount_cents": 999999}'
echo
# expected lần 2: 422 payload mismatch

Bước 6 — ép nó vỡ để so sánh. Trong server.js, thay khối INSERT ... ON CONFLICT DO NOTHING bằng "SELECT rồi nếu không có thì INSERT INTO charges" (check-then-act không atomic). TRUNCATE charges, idempotency_keys rồi chạy lại Test B — count sẽ lên 8: mất dedup, double (thực ra octuple) charge. Đây là failure mode 1.

Bước 7 — thêm một counter Prometheus cho nhánh ins.rowCount === 0 (duplicate hit) và một cho nhánh 422 (payload mismatch). Chạy Test A + Test B + Test C xen kẽ, scrape /metrics, xác nhận duplicate rate và payload mismatch rate khớp với hành vi test. Cuối cùng, thêm một background job DELETE FROM idempotency_keys WHERE created_at < now() - interval '10 seconds' chạy mỗi 5 giây; gửi request với key K, đợi 20 giây rồi retry cùng key K — kết quả sẽ tạo charge thứ hai, tái hiện failure mode 6 "TTL cắt trước retry window".

Rate Limiting — Throttling

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:37 +0000

Throttling: vì sao in-memory rate limit "biến mất" sau khi scale ngang, và chọn token bucket hay sliding window

Throttling là cơ chế giới hạn số request một client (user, IP, API key, tenant) được xử lý trong một khoảng thời gian, để chống abuse, bảo vệ downstream, và phân bổ công bằng dung lượng service. Định nghĩa nghe đơn giản, nhưng lý do dev gặp nó trong việc thật lại rất cụ thể: sau khi scale service từ 1 pod lên 8 pod, cùng cấu hình "100 req/min mỗi user" đột nhiên trở thành 800 req/min thực tế — vì mỗi pod đếm riêng trong RAM, và load balancer rải request đều tám hướng. Rate limit vẫn "chạy", log không có lỗi, nhưng downstream vẫn bị flood. Đó là failure mode dẫn tới việc phải chuyển counter sang store phân tán, và kèm theo là câu hỏi chọn algorithm nào — token bucket, sliding window, hay leaky bucket — mỗi cái đánh đổi khác nhau.

Cơ chế hoạt động

Bốn thuật toán phổ biến, khác nhau ở cách đếm và cách xử lý burst.

Fixed window counter. Chia thời gian thành khung cố định (mỗi phút bắt đầu tại giây 0). Mỗi request INCR một key rl:{user}:{minute}, nếu counter vượt limit thì reject. Đơn giản nhất, một INCR + EXPIRE trên Redis là xong. Nhược điểm cứng: tại biên khung có thể chịu gấp đôi limit trong một cửa sổ trượt — user gửi 100 req vào giây 59 của phút 12:00, rồi 100 req vào giây 01 của phút 12:01, tức 200 req trong 2 giây thật, trong khi limit là 100/phút.

Sliding window log. Lưu timestamp của từng request trong sorted set, mỗi request ZADD + ZREMRANGEBYSCORE xoá các entry cũ hơn now - window, rồi ZCARD để đếm. Chính xác tuyệt đối nhưng tốn bộ nhớ tuyến tính theo số request.

Sliding window counter. Cách Cloudflare mô tả trên engineering blog: giữ counter của khung hiện tại và khung trước, ước lượng lượng request trong cửa sổ trượt bằng nội suy có trọng số theo phần trăm khung trước còn nằm trong window. Chỉ tốn hai counter, sai số rất nhỏ so với log thuần, và không có failure mode biên như fixed window.

Token bucket. Bucket có capacity B token, refill với tốc độ r token/s. Mỗi request tiêu một token; hết token thì reject. Cho phép burst tới B khi bucket đầy, nhưng steady-state trung bình vẫn bằng r. Đây là thuật toán Stripe mô tả trong bài "Scaling your API with rate limiters" và cũng là gốc của GCRA (Generic Cell Rate Algorithm) mà redis-cell module implement dưới lệnh CL.THROTTLE.

Bản token bucket phân tán trên Redis phải atomic — không dùng GET rồi SET (race condition kinh điển). Dùng Lua script để read-modify-write trong một round trip:

-- token_bucket.lua — KEYS[1]=bucket key, ARGV: capacity, refill_rate, now_ms, cost
local key       = KEYS[1]
local capacity  = tonumber(ARGV[1])
local rate      = tonumber(ARGV[2])   -- tokens/sec
local now       = tonumber(ARGV[3])   -- ms
local cost      = tonumber(ARGV[4])

local data = redis.call('HMGET', key, 'tokens', 'ts')
local tokens = tonumber(data[1]) or capacity
local ts     = tonumber(data[2]) or now

-- refill dựa trên khoảng thời gian trôi qua
local delta = math.max(0, now - ts) / 1000.0
tokens = math.min(capacity, tokens + delta * rate)

local allowed = 0
if tokens >= cost then
  tokens = tokens - cost
  allowed = 1
end

redis.call('HMSET', key, 'tokens', tokens, 'ts', now)
-- TTL đủ dài để refill từ empty về full, +biên
redis.call('PEXPIRE', key, math.ceil(capacity / rate * 1000) + 1000)
return { allowed, tokens }

Client gọi:

// Node + ioredis; script được EVALSHA sau khi SCRIPT LOAD một lần
const [allowed, remaining] = await redis.evalsha(
  SHA, 1, `rl:${userId}`, 100, 10, Date.now(), 1  // cap=100, 10 tok/s
)
if (!allowed) {
  res.set('Retry-After', '1')
  return res.status(429).json({ error: 'rate_limited' })
}

Hai điểm mấu chốt: (1) toàn bộ logic chạy trong Redis dưới dạng script atomic — không có window giữa GET và SET cho hai request cùng chạy race; (2) PEXPIRE đảm bảo key idle được thu hồi, nếu không mỗi user id sinh một key vĩnh viễn và Redis phình memory. Với sliding window counter thì cùng nguyên tắc: một Lua script đọc counter hai khung, tính weighted sum, INCR khung hiện tại nếu allow.

Trong HTTP, response reject trả 429 Too Many Requests (RFC 6585) kèm Retry-After (giây hoặc HTTP date) và thường thêm X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset — pattern GitHub API dùng, nhiều SDK tự parse.

Vấn đề gặp trong production

Failure mode 1: rate limit in-memory không chia sẻ khi scale ngang. Đây là failure mode kinh điển và cũng là lý do đề bài luôn quay lại "distributed store". App dùng express-rate-limit mặc định (in-memory Map) hoặc một object counter tự viết:

// sai — mỗi pod đếm riêng
const counters = new Map()  // userId -> { count, resetAt }
app.use((req, res, next) => {
  const now = Date.now()
  const c = counters.get(req.userId) ?? { count: 0, resetAt: now + 60_000 }
  if (now > c.resetAt) { c.count = 0; c.resetAt = now + 60_000 }
  if (++c.count > 100) return res.status(429).end()
  counters.set(req.userId, c)
  next()
})

Chạy 1 pod thì đúng. Scale lên N pod sau load balancer round-robin: total budget cho một user trở thành N × 100/phút, và không có cách nào phía app phát hiện vì mỗi pod thấy counter riêng vẫn dưới ngưỡng. Downstream (DB, third-party API) nhận flood, mọi user khác chậm theo. Bản đúng là đưa counter ra store dùng chung — Redis là mặc định, hoặc dùng một sidecar/service ratelimit chuyên biệt như Envoy ratelimit:

// đúng — Redis-backed token bucket atomic
const [allowed] = await redis.evalsha(SHA, 1, `rl:${req.userId}`, 100, 10/6, Date.now(), 1)
if (!allowed) return res.status(429).set('Retry-After', '1').end()

Failure mode 2: race condition khi implement token bucket bằng GET + SET. Một variation tinh vi: dev biết cần Redis, nhưng viết logic ở app layer:

// sai — TOCTOU giữa GET và SET
const tokens = Number(await redis.get(`rl:${uid}`))
if (tokens <= 0) return res.status(429).end()
await redis.set(`rl:${uid}`, tokens - 1)

Hai request song song đều đọc tokens=1, cả hai đều pass check, cả hai đều set về 0 — một token bị tiêu hai lần. Với QPS cao, sai lệch tích lại đáng kể. Sửa bằng INCR/DECR (atomic single-op) cho fixed window, hoặc Lua script cho logic phức tạp hơn như token bucket/sliding window. WATCH/MULTI cũng làm được nhưng cost cao hơn Lua vì có retry loop.

Failure mode 3: fixed window boundary burst. Cấu hình "100 req/phút", user gửi 100 req vào 12:00:59.9 và 100 req nữa vào 12:01:00.1 — cùng cửa sổ trượt 2 giây nhận 200 req. Nếu downstream sensitive với burst (payment provider, DB có connection pool nhỏ), số spike thật cao hơn expected 2x. Chuyển sang sliding window counter hoặc token bucket triệt tiêu vấn đề này. Nếu vẫn muốn giữ fixed window vì đơn giản, thêm một token bucket capacity nhỏ chạy song song để chặn burst (kiểu "sustained rate + burst limit" — Stripe dùng nhiều tầng như thế).

Failure mode 4: Redis là single point of failure cho rate limit. Khi Redis down, mọi call EVALSHA fail. Hai lựa chọn phải quyết trước:

Fail-open: nếu Redis lỗi, cho qua. An toàn cho availability nhưng bỏ trống chống abuse trong khoảng lỗi — attacker biết pattern có thể ép Redis chậm để né limit.
Fail-closed: nếu Redis lỗi, reject. An toàn chống abuse nhưng biến sự cố Redis thành sự cố toàn service.

Production thường fail-open có timeout ngắn (vài chục ms) kèm alert, cộng thêm một layer L7 (Nginx limit_req, Envoy local rate limit) chạy per-instance với ngưỡng rộng như safety net:

try {
  const [allowed] = await Promise.race([
    redis.evalsha(SHA, 1, key, ...args),
    new Promise((_, rj) => setTimeout(() => rj(new Error('rl_timeout')), 50)),
  ])
  if (!allowed) return res.status(429).end()
} catch (err) {
  metrics.increment('ratelimit.fail_open')  // alert khi metric này > 0
  // cho qua, fallback layer ngoài sẽ chặn abuse cực đoan
}
next()

Failure mode 5: hot key trên Redis do một tenant lớn. Rate limit key cho một API key traffic cao (crawler, mobile client phổ biến) trở thành hot key — mọi request đều EVALSHA vào cùng một slot Redis, một node cluster gánh nặng bất đối xứng. Sharding rate limit theo user cứu được phần lớn user, nhưng không giải quyết tenant khổng lồ. Cách xử lý: shard key thêm theo bucket con (rl:{user}:{bucket=hash(req_id)%K}) rồi cộng dồn, hoặc dùng thuật toán probabilistic (approximated counting) để tolerate sai số nhỏ đổi lấy phân tải. Với API gateway thật (Envoy ratelimit, Kong), cấu hình local rate limit trước global rate limit để cắt phần lớn traffic ngay tại pod, chỉ traffic còn lại mới hỏi service tập trung.

Failure mode 6: không phân biệt được ai đang bị limit. Rate limit theo IP đơn thuần đụng NAT (một văn phòng hàng trăm user chung một IP public bị limit như một user), hoặc đụng CDN/proxy (mọi request đến từ IP CDN). Cấu hình limit_req_zone của Nginx theo $binary_remote_addr mà không set real_ip_header đúng sẽ throttle theo IP CDN. Với API cần authenticated, key limit theo user_id hoặc api_key; với public endpoint, kết hợp IP + fingerprint (User-Agent + Accept-Language + đặc trưng TLS) để tránh cả false positive lẫn false negative. Trust source của IP thật (header X-Forwarded-For phải được validate từ proxy tin cậy, không phải từ client tuỳ ý).

Cách debug và monitor

Triệu chứng chính khi rate limit sai: (a) downstream vẫn thấy tải cao hơn expected dù rate limit "đang chạy" — dấu hiệu multi-instance drift hoặc race condition; (b) reject rate tăng đột biến cho một nhóm user hợp pháp — dấu hiệu key sai (limit theo IP mà user sau NAT chung), hoặc ngưỡng quá thấp so với UX thật; (c) reject rate = 0 kéo dài trong khi log downstream có timeout — rate limit không hiệu lực (fail-open đang che, hoặc key không match).

Metric bắt buộc:

Reject rate (số 429 / tổng request) tổng, và slice theo tenant/route. Đây là chỉ số hàng đầu — reject rate 0% nghĩa là limit chưa bao giờ kích, ngưỡng có thể quá cao (hoặc code không gọi tới limiter); reject rate > vài phần trăm liên tục nghĩa là ngưỡng quá thấp hoặc có abuse thật.
Top rejected keys — user_id/api_key/IP bị reject nhiều nhất. Phân biệt "một attacker bị chặn" (đúng) vs "top là user hợp pháp" (ngưỡng sai).
Redis latency của rate limit ops — redis-cli --latency hoặc metric client (ioredis/lettuce exporter). Latency tăng là dấu hiệu hot key hoặc script chậm.
Fail-open counter — mọi lần Redis timeout mà rate limit cho qua đều tăng counter này; alert khi > 0 kéo dài.
429 response headers accuracy — kiểm tra X-RateLimit-Remaining giảm đúng nhịp bằng cách bắn traffic có kiểm soát và so; nếu client thấy Remaining không giảm nhưng vẫn bị 429, header sinh sai.

Công cụ chẩn đoán: redis-cli MONITOR để xem lệnh thật đang chạy (không dùng lâu vì tốn CPU Redis); redis-cli --hotkeys (Redis phải bật maxmemory-policy allkeys-lfu) để tìm hot key; SLOWLOG GET để xem script Lua chậm; CLIENT LIST xem connection distribution. Với Envoy ratelimit, ratelimit_service.total_hits và ratelimit_service.over_limit là hai metric chính. Với Nginx limit_req, log format ghi $limit_req_status cho biết một request được PASSED, DELAYED, hay REJECTED.

Rule phòng ngừa: (1) không bao giờ dùng counter in-memory cho rate limit ở service scale ngang — mặc định là distributed store; (2) mọi read-modify-write phải atomic (Lua script hoặc single-op như INCR); (3) chọn key limit theo entity thực sự cần chống abuse (user_id / api_key), không mặc định IP; (4) chạy hai tầng — local burst limit tại proxy + global sustained limit qua Redis — để cắt phần lớn traffic trước khi tới store trung tâm; (5) load test rate limit path chính với QPS thật để verify không sai số dưới tải.

Tradeoff

Rate limit chống abuse, bảo vệ downstream, phân bổ công bằng — nhưng mọi lựa chọn implementation đều đánh đổi.

Fixed window: rẻ nhất (một INCR), memory ít nhất (một key per user per window), nhưng chịu boundary burst 2x. Phù hợp cho limit "thô" chống abuse thô bạo.

Sliding window log: chính xác nhất, không có burst effect, nhưng memory tuyến tính theo số request — không dùng được khi limit lớn và traffic cao.

Sliding window counter: gần chính xác như log, memory bằng fixed window (hai counter), sai số vài phần trăm. Sweet spot cho phần lớn use case API rate limit.

Token bucket / GCRA: cho phép burst có kiểm soát (capacity), steady-state chính xác, tự nhiên khớp với "user thi thoảng bắn liên tiếp là hợp lệ". Tốn hơn fixed window (Lua script) nhưng đáng.

Local vs distributed store: local (in-memory hoặc Nginx limit_req_zone per-worker) nhanh nhất, không network hop, nhưng sai số N-instance drift. Distributed (Redis-backed) chính xác toàn cục, nhưng thêm latency mỗi request (thường vài ms) và Redis thành dependency phải HA + monitor. Hybrid — local burst cap + global sustained — là kiến trúc Stripe và Envoy khuyến nghị.

Fail-open vs fail-closed khi store lỗi: fail-open ưu tiên availability, hy sinh chống abuse; fail-closed ngược lại. Production thường fail-open với timeout ngắn + safety net local + alert.

Rule of thumb: mặc định là sliding window counter hoặc token bucket, backed bằng Redis + Lua script atomic, key theo entity thật (user_id/api_key), fail-open với timeout ~50ms và alert, kèm một local burst cap tại proxy. Chỉ chọn fixed window khi biết chắc chấp nhận được biên burst, và chỉ giữ in-memory khi service dứt khoát single-instance.

Câu hỏi phỏng vấn

Token bucket và sliding window khác nhau thế nào, và khi scale ngang thì rate limit thay đổi ra sao?

Token bucket có một bucket capacity B refill với rate r token/s: mỗi request tiêu một token, hết token thì reject. Nó cho phép burst tới B khi bucket đầy (user vừa mới im lặng lâu có thể bắn nhanh một loạt), còn steady-state trung bình vẫn bằng r. Sliding window (counter) đếm số request trong một cửa sổ trượt liên tục — không có khái niệm burst credit, hai request cách nhau đúng bằng 1/limit là ngưỡng. Token bucket phù hợp khi user thật hay có bursty traffic hợp lệ (mobile app đồng bộ khi mở, batch script); sliding window phù hợp khi cần rate đều tay để bảo vệ downstream nhạy cảm với spike. Fixed window là cách rẻ nhất nhưng chịu boundary burst 2x, sliding window counter (như Cloudflare mô tả) khắc phục bằng nội suy hai khung.

Khi scale ngang từ 1 lên N pod, rate limit in-memory trở thành N × limit thực tế vì mỗi pod đếm riêng — đây là failure mode cần xử lý bằng distributed store. Cách chuẩn là đưa counter vào Redis với atomic op (INCR cho fixed window, hoặc Lua script cho token bucket/sliding window) để tránh race giữa GET và SET. Điểm ăn điểm là gọi được thêm: (1) Redis biến rate limit thành dependency, cần fail-open + timeout ngắn + alert để không biến sự cố Redis thành sự cố cả service; (2) hot key khi một tenant lớn dồn về một Redis slot — giải bằng shard con hoặc hai tầng (local burst limit + global limit); (3) chọn entity limit đúng (user_id/api_key, không phải IP thuần vì NAT/CDN); (4) monitor bằng reject rate + top rejected keys + Redis latency + fail-open counter, không chỉ "có 429 hay không".

Hands-on

Dựng Redis + hai instance Node app, đo hiệu ứng multi-instance drift với in-memory limiter, rồi chuyển sang distributed token bucket qua Lua script và xác nhận rate thực sự đúng ngưỡng.

docker run -d --name rl-redis -p 6379:6379 redis:7-alpine
mkdir throttle-lab && cd throttle-lab
npm init -y
npm i express ioredis

Tạo app-inmem.js (bản sai — in-memory Map):

// app-inmem.js
const express = require('express')
const app = express()
const counters = new Map()
const LIMIT = 10, WINDOW_MS = 10_000  // 10 req / 10s / user

app.get('/api', (req, res) => {
  const uid = req.query.uid || 'anon'
  const now = Date.now()
  let c = counters.get(uid)
  if (!c || now > c.resetAt) c = { count: 0, resetAt: now + WINDOW_MS }
  c.count++
  counters.set(uid, c)
  if (c.count > LIMIT) return res.status(429).json({ err: 'rate_limited' })
  res.json({ ok: true, port: process.env.PORT, count: c.count })
})
app.listen(process.env.PORT)

Tạo token_bucket.lua:

local key = KEYS[1]
local cap = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local cost = tonumber(ARGV[4])
local d = redis.call('HMGET', key, 't', 'ts')
local t = tonumber(d[1]) or cap
local ts = tonumber(d[2]) or now
t = math.min(cap, t + math.max(0, now - ts) / 1000.0 * rate)
local allow = 0
if t >= cost then t = t - cost; allow = 1 end
redis.call('HMSET', key, 't', t, 'ts', now)
redis.call('PEXPIRE', key, math.ceil(cap / rate * 1000) + 1000)
return { allow, tostring(t) }

Tạo app-redis.js (bản đúng — distributed):

// app-redis.js
const express = require('express')
const Redis = require('ioredis')
const fs = require('fs')
const app = express()
const redis = new Redis({ host: '127.0.0.1', port: 6379 })
const SCRIPT = fs.readFileSync('./token_bucket.lua', 'utf8')
let SHA
const CAP = 10, RATE = 1  // capacity 10, refill 1 token/s

app.get('/api', async (req, res) => {
  const uid = req.query.uid || 'anon'
  try {
    const [allow, remaining] = await Promise.race([
      redis.evalsha(SHA, 1, `rl:${uid}`, CAP, RATE, Date.now(), 1),
      new Promise((_, rj) => setTimeout(() => rj(new Error('rl_timeout')), 50)),
    ])
    if (!allow) {
      res.set('Retry-After', '1')
      return res.status(429).json({ err: 'rate_limited', remaining })
    }
    res.json({ ok: true, port: process.env.PORT, remaining })
  } catch (e) {
    console.error('fail_open', e.message)
    res.json({ ok: true, port: process.env.PORT, degraded: true })
  }
})

;(async () => {
  SHA = await redis.script('LOAD', SCRIPT)
  app.listen(process.env.PORT, () => console.log('listening', process.env.PORT))
})()

Chạy hai instance bản in-memory và bắn traffic rải đều hai port để mô phỏng load balancer round-robin:

PORT=3001 node app-inmem.js &
PORT=3002 node app-inmem.js &
sleep 1
# 40 req cùng uid=alice, LIMIT là 10/10s
for i in $(seq 1 40); do
  port=$([ $((i % 2)) -eq 0 ] && echo 3001 || echo 3002)
  curl -s -o /dev/null -w "%{http_code} " "http://127.0.0.1:$port/api?uid=alice"
done; echo
# Kỳ vọng: mỗi pod cho qua ~10 → tổng ~20 pass thay vì đúng 10
# → chính là multi-instance drift, budget thực = N × config

Kill hai process và chạy bản Redis:

kill %1 %2 2>/dev/null
PORT=3001 node app-redis.js &
PORT=3002 node app-redis.js &
sleep 1
for i in $(seq 1 40); do
  port=$([ $((i % 2)) -eq 0 ] && echo 3001 || echo 3002)
  curl -s -o /dev/null -w "%{http_code} " "http://127.0.0.1:$port/api?uid=alice"
done; echo
# Kỳ vọng: đúng ~10 pass 200 (capacity bucket), phần còn lại 429
# bất kể request rơi vào pod nào

Quan sát Redis state trong lúc chạy:

docker exec -it rl-redis redis-cli
# > HGETALL rl:alice
# > MONITOR      # xem EVALSHA thực tế của cả hai pod bắn vào cùng key
# > SLOWLOG GET 10

Test hot key bằng redis-benchmark:

docker exec -it rl-redis redis-benchmark -n 100000 -c 50 -t evalsha -r 1
# so với: docker exec -it rl-redis redis-benchmark -n 100000 -c 50 -t evalsha -r 1000
# key range 1 vs 1000 cho khác biệt latency rõ — đó là hot-key effect

Test fail-open: dừng Redis khi app đang chạy và xác nhận request vẫn được trả (kèm degraded: true), rồi start lại Redis và verify limit lại kích hoạt:

docker stop rl-redis
curl -s "http://127.0.0.1:3001/api?uid=alice" | grep degraded
# expected: {"ok":true,"port":"3001","degraded":true}
docker start rl-redis
sleep 2
# gọi liên tiếp 20 lần, phần lớn phải 429 vì bucket đã cạn
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code} " "http://127.0.0.1:3001/api?uid=alice"
done; echo

Cuối cùng, so sánh boundary burst giữa fixed window (thay Lua bằng INCR + EXPIRE 60) và token bucket bằng cách bắn 100 request vào giây thứ 59 rồi 100 request nữa vào giây thứ 61 — fixed window cho qua tất cả 200 trong 2 giây thật, token bucket cắt đúng theo capacity + refill. Đó là bằng chứng nhìn thấy được cho tradeoff algorithm ở phần Tradeoff phía trên.

Message Queue — Async Processing

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:33 +0000

Async processing qua message queue: vì sao đẩy việc nặng ra khỏi request path, và cái giá phải trả bằng eventual consistency

Async processing là mô hình tách một request thành hai giai đoạn: request handler nhận việc, xác nhận với client, rồi giao phần xử lý thật cho một worker chạy ngoài request path — thường qua một message queue (RabbitMQ, AWS SQS, Kafka, Redis Streams, hoặc queue trên nền Redis như BullMQ/Sidekiq). Lý do dev gặp nó trong việc thật rất cụ thể: một endpoint gọi payment provider mất 3s, gửi email confirm mất 1s, resize ảnh mất 5s — nếu làm tuần tự trong request, p99 latency của endpoint là tổng các con số đó, và một downstream chậm hoặc chết đủ để làm timeout hết thread pool của app server. Đẩy vào queue thì request trả về trong vài chục ms; nhưng đổi lại, cái "xong" mà client thấy không còn nghĩa là việc đã thực sự hoàn thành.

Cơ chế hoạt động

Ba thành phần: producer (thường là API server) đóng gói việc thành message rồi publish vào broker; broker (RabbitMQ/SQS/Kafka…) giữ message trong queue có persistence tuỳ cấu hình; consumer/worker poll hoặc được push message, xử lý, rồi ack để broker biết xoá. Nếu worker chết trước khi ack, broker redeliver — đây là gốc của semantic at-least-once: mỗi message được giao ít nhất một lần, có thể nhiều lần. Exactly-once trong hệ phân tán chỉ đạt được ở lớp application bằng cách consumer viết idempotent, không phải bằng cấu hình broker.

Ví dụ với RabbitMQ + Node (amqplib):

// producer — trong HTTP handler
const ch = await conn.createConfirmChannel()
await ch.assertQueue('image.resize', { durable: true })
app.post('/upload', async (req, res) => {
  const jobId = crypto.randomUUID()
  const payload = Buffer.from(JSON.stringify({ jobId, s3Key: req.body.key }))
  await ch.sendToQueue('image.resize', payload, {
    persistent: true,        // ghi xuống disk, sống sót broker restart
    messageId: jobId,        // để consumer dedupe
    contentType: 'application/json',
  })
  // đợi broker confirm đã nhận (publisher confirm)
  await ch.waitForConfirms()
  res.status(202).json({ jobId })   // 202 Accepted — chưa xong, đã nhận
})

// consumer — process riêng
const ch = await conn.createChannel()
await ch.prefetch(8)                // chỉ giữ 8 message unacked mỗi consumer
ch.consume('image.resize', async (msg) => {
  try {
    const job = JSON.parse(msg.content.toString())
    await resizeAndUpload(job)      // việc thật
    ch.ack(msg)
  } catch (err) {
    // requeue = false → gửi sang dead-letter exchange đã config
    ch.nack(msg, false, false)
  }
})

Ba chi tiết dễ bỏ sót nhưng quyết định correctness trong production: persistent: true + queue durable: true để message sống sót broker restart; publisher confirm để producer biết broker đã nhận (không có nó thì sendToQueue là fire-and-forget); prefetch để giới hạn số message một consumer giữ, nếu không một consumer chậm sẽ ôm cả queue.

Ngoài "job queue" cổ điển (một producer → một queue → worker pool cạnh tranh), còn hai mô hình hay dùng: pub/sub fanout (một message được nhân bản tới nhiều queue, mỗi consumer group xử lý độc lập — RabbitMQ fanout exchange, Kafka topic với nhiều consumer group) để cùng một event trigger nhiều side-effect độc lập, và log-based queue (Kafka, Redis Streams) nơi message không bị xoá sau khi ack mà tồn theo offset, cho phép replay.

Vấn đề gặp trong production

Failure mode 1: xử lý đồng bộ trong request path. Endpoint đăng ký tài khoản gọi tuần tự: ghi DB, gọi Stripe tạo customer, gửi welcome email qua SendGrid, đẩy analytics event. Tổng latency là tổng của bốn call, và bất kỳ call nào chậm/timeout đều làm cả request fail dù DB đã ghi xong:

// sai — mọi side-effect chặn response
app.post('/signup', async (req, res) => {
  const user = await db.insertUser(req.body)
  await stripe.customers.create({ email: user.email })    // 500ms–timeout
  await sendgrid.send(welcomeEmail(user))                 // vài trăm ms
  await analytics.track('signup', user)                   // vài chục ms
  res.json(user)  // p99 = tổng, và fail-any-fail-all
})

Hậu quả: khi SendGrid chậm, endpoint timeout dù user đã được tạo — client retry, sinh duplicate user; app server thread pool bị các request treo giữ, các endpoint khác cũng chậm theo. Bản đúng là cắt bốn công việc thành bốn message, request chỉ ghi DB + enqueue rồi trả về:

app.post('/signup', async (req, res) => {
  const user = await db.insertUser(req.body)
  // enqueue trong cùng transaction (outbox pattern) — xem failure mode 4
  await outbox.insert([
    { topic: 'billing.create_customer', payload: { userId: user.id } },
    { topic: 'email.send_welcome',      payload: { userId: user.id } },
    { topic: 'analytics.signup',        payload: { userId: user.id } },
  ])
  res.status(201).json(user)   // trả về ngay, worker lo phần còn lại
})

Failure mode 2: queue tăng không kiểm soát khi producer nhanh hơn consumer. Đây là failure mode kinh điển của async processing. Traffic đột biến, producer publish nhiều msg/s, worker pool xử lý chậm hơn — depth tăng tuyến tính. Vì worker vẫn "chạy bình thường" và không có exception, nhiều team không phát hiện cho tới khi user báo "email confirm tới sau vài tiếng" hoặc broker chạm giới hạn memory. RabbitMQ trong tình huống này kích flow control: publisher bị chặn để bảo vệ broker; nếu queue có max-length thì message cũ hoặc mới bị drop tuỳ policy. Cách xử lý: alert trên queue depth và trên oldest message age (không chỉ depth — depth ổn định vẫn có thể che một backlog cũ nếu message mới liên tục vượt lên); autoscale worker theo depth; và dùng backpressure ở producer (nếu depth vượt ngưỡng, degrade sang synchronous hoặc từ chối request non-critical).

Failure mode 3: poison message làm kẹt queue. Một message có payload sai schema, worker throw, không ack, broker redeliver, worker throw tiếp — vòng lặp vô hạn. Nếu consumer requeue vào đầu queue, cùng message chặn mọi message sau nó:

// sai — requeue vô điều kiện
ch.consume(queue, async (msg) => {
  try { await handle(msg); ch.ack(msg) }
  catch { ch.nack(msg, false, true) }   // requeue = true → poison loop
})

Bản đúng: đếm redelivery, sau N lần đẩy sang dead-letter queue (DLQ) để xử lý thủ công, không chặn hàng chính. RabbitMQ config x-dead-letter-exchange trên queue; SQS có RedrivePolicy với maxReceiveCount; Kafka không có DLQ built-in nhưng convention là producer publish message hỏng sang topic *.dlq.

Failure mode 4: mất message vì dual-write giữa DB và queue. Handler ghi DB rồi publish message; giữa hai bước, process crash — DB có record, queue không có event. Hoặc ngược lại: publish trước, ghi DB fail — event tồn tại cho một record không có thật. Đây là bài toán dual-write không thể giải bằng try/catch. Giải pháp production-grade là transactional outbox: trong cùng DB transaction với business write, insert một row vào bảng outbox; một relay process (hoặc CDC như Debezium đọc WAL) đọc bảng đó và publish sang queue, đánh dấu row đã xử lý. Nếu crash, relay tiếp tục từ row chưa publish — không mất, có thể duplicate (idempotent consumer xử lý).

Failure mode 5: consumer không idempotent. Vì delivery là at-least-once, một message có thể được xử lý hai lần (worker crash sau khi làm việc nhưng trước khi ack, network partition khiến ack không tới broker, redeliver sau visibility timeout của SQS…). Nếu handler tính phí, mỗi lần duplicate là một lần trừ tiền:

// sai — charge mỗi lần message tới
async function handle(msg) {
  const { userId, amount } = JSON.parse(msg.content)
  await stripe.charges.create({ amount, customer: userId })  // duplicate = double charge
}

// đúng — dedupe theo idempotency key ổn định
async function handle(msg) {
  const { jobId, userId, amount } = JSON.parse(msg.content)
  await stripe.charges.create(
    { amount, customer: userId },
    { idempotencyKey: jobId }   // Stripe dedupe phía server
  )
}

Với side-effect nội bộ (không có provider dedupe), dùng bảng processed_jobs(job_id primary key) insert-if-not-exists trong cùng transaction với business write; nếu insert vi phạm primary key thì bỏ qua message. Message id (RabbitMQ messageId, SQS MessageId, Kafka key+offset) làm idempotency key ổn định.

Failure mode 6: visibility timeout / ack timeout ngắn hơn thời gian xử lý. SQS có visibility timeout mặc định thấp hơn nhiều so với job nặng; nếu job resize ảnh mất lâu hơn ngưỡng, SQS coi worker đã chết và redeliver — hai worker cùng xử lý cùng message. Tương tự RabbitMQ có consumer timeout mặc định (broker huỷ channel nếu delivery không ack trong ngưỡng). Cách xử lý: đặt visibility timeout dài hơn p99 xử lý cộng biên; với job dài không lường trước, extend visibility định kỳ trong khi vẫn chạy (SQS ChangeMessageVisibility, Kafka heartbeat).

Cách debug và monitor

Triệu chứng backlog: queue depth tăng đơn điệu theo thời gian; oldest message age vượt SLO của loại việc đó (email confirm tới sau vài phút là bất thường); consumer log không có error nhưng throughput giữ nguyên trong khi depth tăng — nghĩa là producer > consumer. Triệu chứng poison: một message id lặp lại nhiều lần trong log kèm stack trace giống hệt; DLQ depth tăng dần trong khi main queue chạy bình thường. Triệu chứng duplicate: business metric (số email gửi, số charge) cao hơn số job enqueue.

Metric bắt buộc theo dõi:

Queue depth / backlog — số message ready. RabbitMQ: rabbitmqctl list_queues name messages messages_ready messages_unacknowledged hoặc endpoint /api/queues của management plugin; scrape bằng rabbitmq_prometheus plugin. SQS: CloudWatch ApproximateNumberOfMessagesVisible. Kafka: consumer lag = high watermark − committed offset, xem qua kafka-consumer-groups.sh --describe hoặc Burrow/kafka-lag-exporter.
Oldest message age — SQS ApproximateAgeOfOldestMessage, RabbitMQ với head message timestamp. Depth có thể ổn định nhưng age tăng nếu có message bị bỏ lại phía sau (nhất là khi ordering + partition).
Consumer throughput (msg/s ack) và processing latency (thời gian từ receive tới ack) — phân biệt "consumer chậm" vs "message ít".
DLQ depth — mọi tăng đều phải alert; DLQ ổn ở 0 hoặc rất thấp.
Redelivery count — RabbitMQ header x-death, SQS ApproximateReceiveCount. Message có count cao là ứng viên poison.
Publisher confirm / publish failure rate — nếu producer không nhận confirm, message có thể chưa vào broker.

Tool chẩn đoán: rabbitmqctl list_queues để chụp nhanh, rabbitmq_prometheus + Grafana cho dashboard, AWS Console/CloudWatch cho SQS, kafka-consumer-groups.sh --describe --group <g> cho lag Kafka. Khi debug một job cụ thể, log message id ở cả producer và consumer để trace end-to-end; nếu có tracing (OpenTelemetry), inject trace context vào message header và tiếp tục span ở consumer.

Rule phòng ngừa: (1) mọi queue có DLQ + alert trên DLQ depth > 0; (2) mọi consumer idempotent, không có ngoại lệ; (3) mọi producer dùng publisher confirm hoặc outbox — không fire-and-forget cho việc quan trọng; (4) alert trên oldest message age, không chỉ depth; (5) load test để biết throughput baseline của worker, autoscale theo depth với ceiling để không đè chết downstream.

Tradeoff

Queue decouple producer khỏi consumer — producer không cần biết consumer còn sống, không bị block khi consumer chậm, có thể scale hai bên độc lập. Queue smooth tải — spike traffic được absorb vào depth, worker rút với tốc độ ổn định thay vì để downstream sập. Queue cho phép retry ở tầng infra — worker crash, broker redeliver, không phải viết retry logic trong app.

Cái giá: (1) eventual consistency — client nhận 202 nghĩa là "đã nhận", không phải "đã xong"; UI phải phản ánh đúng trạng thái (polling job status, hoặc optimistic + reconcile), business rule không được giả định side-effect xong ngay; (2) thêm hạ tầng — broker phải HA, phải monitor, phải backup, phải upgrade; một component thêm là một nguồn incident thêm; (3) at-least-once đẩy gánh idempotency về consumer — mọi handler side-effect phải có dedupe key; (4) debug phức tạp hơn — flow không còn là stack trace một request, phải trace qua queue, log message id, có khi phải replay từ DLQ; (5) ordering không miễn phí — muốn giữ thứ tự phải hy sinh parallelism (single consumer per queue, hoặc partition theo key).

Rule of thumb: đẩy vào queue mọi thứ (a) không cần đồng bộ với response cho user, (b) có side-effect ra hệ khác (email, payment, third-party API), (c) tốn nhiều hơn khoảng một trăm ms hoặc có tail latency dài; giữ đồng bộ mọi thứ user cần thấy kết quả ngay (đọc dữ liệu vừa write, validate form). Nếu chọn async, mặc định at-least-once + idempotent consumer + DLQ + outbox — thiếu bất kỳ mảnh nào trong bốn mảnh này là để lại failure mode chờ nổ.

Câu hỏi phỏng vấn

Khi nào nên dùng message queue thay vì xử lý đồng bộ trong request, và những failure mode nào phải chuẩn bị trước khi đưa lên production?

Dùng queue khi công việc (a) không cần trả kết quả ngay cho client — email, notification, analytics, index update; (b) gọi third-party có tail latency dài hoặc SLA không đảm bảo — payment provider, mail service; (c) là fan-out một event tới nhiều consumer độc lập; (d) cần smooth spike traffic để bảo vệ downstream. Giữ đồng bộ nếu client cần thấy kết quả tức thì hoặc business rule cần strong consistency (đọc lại chính write vừa làm). Cơ chế cốt lõi: producer publish → broker persist → worker consume + ack; nếu worker chết trước ack, broker redeliver — nên delivery là at-least-once, không phải exactly-once. Failure mode phải chuẩn bị: (1) queue backlog khi producer nhanh hơn consumer — cần alert trên depth và oldest message age, autoscale worker, backpressure ở producer; (2) poison message — mọi queue phải có DLQ với maxReceiveCount, không requeue vô điều kiện; (3) dual-write giữa DB và queue — dùng transactional outbox (insert vào bảng outbox trong cùng DB transaction, relay đọc và publish) để không mất event khi crash giữa hai bước; (4) duplicate delivery — consumer phải idempotent, dùng message id làm dedupe key hoặc idempotency key với provider (ví dụ Stripe idempotency key); (5) visibility timeout ngắn hơn thời gian xử lý — extend visibility định kỳ hoặc đặt timeout lớn hơn p99. Điểm ăn điểm là gọi đúng tên at-least-once + outbox + DLQ + idempotent consumer như một bộ tứ không thể thiếu, và nêu concrete metric (queue depth, oldest message age, DLQ depth, consumer lag) chứ không nói chung "monitor queue".

Hands-on

Dựng một RabbitMQ local, tái hiện backlog khi consumer chậm, thêm DLQ cho poison message, và xác nhận idempotent consumer chịu được duplicate.

docker run -d --name rmq -p 5672:5672 -p 15672:15672 \
  -e RABBITMQ_DEFAULT_USER=dev -e RABBITMQ_DEFAULT_PASS=dev \
  rabbitmq:3-management
# UI: http://localhost:15672  (dev/dev)

Tạo project:

mkdir queue-lab && cd queue-lab
npm init -y
npm i amqplib

Tạo setup.js để declare queue chính + DLQ:

const amqp = require('amqplib')
;(async () => {
  const conn = await amqp.connect('amqp://dev:dev@localhost')
  const ch = await conn.createChannel()
  await ch.assertExchange('jobs.dlx', 'direct', { durable: true })
  await ch.assertQueue('jobs.dlq', { durable: true })
  await ch.bindQueue('jobs.dlq', 'jobs.dlx', 'image.resize')
  await ch.assertQueue('image.resize', {
    durable: true,
    arguments: {
      'x-dead-letter-exchange': 'jobs.dlx',
      'x-dead-letter-routing-key': 'image.resize',
    },
  })
  console.log('queues ready')
  await conn.close()
})()

Tạo producer.js bắn 5000 job:

const amqp = require('amqplib')
const crypto = require('crypto')
;(async () => {
  const conn = await amqp.connect('amqp://dev:dev@localhost')
  const ch = await conn.createConfirmChannel()
  for (let i = 0; i < 5000; i++) {
    const jobId = crypto.randomUUID()
    const poison = i % 100 === 0   // 1% poison để test DLQ
    const payload = Buffer.from(JSON.stringify({ jobId, poison, i }))
    ch.sendToQueue('image.resize', payload, {
      persistent: true, messageId: jobId,
    })
  }
  await ch.waitForConfirms()
  console.log('published 5000')
  await conn.close()
})()

Tạo consumer.js xử lý chậm + idempotent + DLQ khi payload hỏng:

const amqp = require('amqplib')
const processed = new Set()  // production: bảng DB có primary key

async function work({ jobId, poison }) {
  if (processed.has(jobId)) return   // idempotent
  if (poison) throw new Error('bad payload')
  await new Promise(r => setTimeout(r, 50))
  processed.add(jobId)
}

;(async () => {
  const conn = await amqp.connect('amqp://dev:dev@localhost')
  const ch = await conn.createChannel()
  await ch.prefetch(4)
  ch.consume('image.resize', async (msg) => {
    const body = JSON.parse(msg.content.toString())
    try {
      await work(body)
      ch.ack(msg)
    } catch (err) {
      // requeue=false → route qua x-dead-letter-exchange sang DLQ
      ch.nack(msg, false, false)
    }
  })
  console.log('consuming...')
})()

Chạy và quan sát:

node setup.js
node consumer.js &
node producer.js

# xem depth tăng vọt rồi rút chậm
watch -n 1 'docker exec rmq rabbitmqctl list_queues name messages messages_ready messages_unacknowledged'

# xem DLQ nhận ~50 poison message (1% của 5000)
docker exec rmq rabbitmqctl list_queues name messages | grep dlq

Kỳ vọng: main queue depth nhảy lên gần 5000 rồi rút dần với tốc độ tương ứng với prefetch × số consumer. DLQ tăng dần lên khoảng 50 khi các poison message rớt qua. Chạy node consumer.js & thêm vài lần để có 4 consumer song song, depth rút nhanh gấp bốn. Chạy lại node producer.js khi consumer đang bận: xác nhận request producer không bị chặn — đó chính là decoupling nhìn thấy được. Cuối cùng, replay DLQ bằng cách viết một script nhỏ đọc jobs.dlq, sửa payload, publish lại sang image.resize sau khi đã fix bug producer — đây là workflow xử lý DLQ trong production thật.

Cache Invalidation — Stale Data

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:30 +0000

Stale data và cache stampede: vì sao TTL một mình không đủ và vì sao origin sập khi key hết hạn

Stale data là dữ liệu trong cache đã lỗi thời so với source of truth. Nó xuất hiện vì cache và origin là hai bản sao, và bất kỳ cơ chế đồng bộ nào — TTL, event-based invalidation, versioning — đều có cửa sổ giữa lúc origin đổi và lúc cache biết chuyện. Cái giá phải trả trong production không chỉ là "user nhìn thấy giá cũ vài giây". Khi một key hot vừa hết hạn, hàng nghìn request cùng miss, cùng đâm xuống DB để tính lại — đó là cache stampede (dogpile, thundering herd), và nó đủ sức đưa origin xuống trong vài chục giây.

Cơ chế hoạt động

Có bốn cơ chế invalidation dùng thật:

TTL (time-to-live). Mỗi entry gắn một hạn dùng. Hết hạn coi như miss, đọc lại từ origin. Đơn giản, không cần coordination giữa writer và cache. Nhược điểm: staleness bounded bởi TTL, và tất cả replica của cùng một key hết hạn cùng lúc.

Event-based invalidation. Khi origin thay đổi, phát một event (thường qua pub/sub, CDC như Debezium, hoặc gọi trực tiếp DEL) để cache xoá hoặc cập nhật entry. Fresh gần như realtime, nhưng đòi hỏi coupling giữa write path và cache — writer phải biết mọi key phái sinh từ dữ liệu vừa đổi.

Versioning (cache key có version). Key gắn version của dữ liệu, ví dụ user:123:v42. Đổi dữ liệu thì tăng version, key cũ tự nhiên bị bỏ qua, không cần xoá gì. Kỹ thuật này còn được gọi là generational caching; Rails cache dùng cách tương tự với cache_key_with_version.

Single-flight (request coalescing). Không phải invalidation, mà là cách xử lý miss: khi N request cùng miss cùng một key, chỉ một trong số đó được phép gọi origin, các request còn lại đợi kết quả của nó. Go có golang.org/x/sync/singleflight implement sẵn pattern này; Facebook memcache dùng "leases" (paper của Nishtala et al., NSDI 2013) cho cùng ý tưởng ở scale phân tán.

Kết hợp điển hình: TTL để bounded staleness, single-flight để chặn stampede khi key hết hạn, event-based invalidation để cắt TTL sớm khi có write. Ví dụ single-flight với Redis SETNX làm distributed lock:

func GetOrLoad(ctx context.Context, key string, ttl time.Duration, load func() ([]byte, error)) ([]byte, error) {
    if v, err := rdb.Get(ctx, key).Bytes(); err == nil {
        return v, nil // cache hit
    }
    lockKey := "lock:" + key
    // SET NX PX = chỉ set nếu chưa có, kèm TTL để tránh deadlock nếu holder chết
    ok, _ := rdb.SetNX(ctx, lockKey, "1", 5*time.Second).Result()
    if !ok {
        // request khác đang load; đợi ngắn rồi thử lại cache
        time.Sleep(50 * time.Millisecond)
        return rdb.Get(ctx, key).Bytes()
    }
    defer rdb.Del(ctx, lockKey)
    v, err := load()
    if err != nil {
        return nil, err
    }
    rdb.Set(ctx, key, v, ttl)
    return v, nil
}

Vấn đề gặp trong production

Failure mode 1: cache stampede khi key hot hết hạn. Một product page top-traffic có TTL 60s. Đúng giây thứ 60, mọi replica cache đồng loạt miss; nếu QPS là 10k, thì 10k request cùng gọi cùng một query nặng xuống DB trong cùng một tick. DB connection pool cạn, latency của cả service tăng vọt, health check timeout, autoscaler kích hoạt nhưng không kịp. Code sai điển hình:

func GetProduct(id string) (*Product, error) {
    if v, ok := cache.Get(id); ok {
        return v.(*Product), nil
    }
    // N request cùng vào đây khi key vừa hết hạn
    p, err := db.QueryProduct(id) // origin ăn N query cùng lúc
    if err != nil {
        return nil, err
    }
    cache.Set(id, p, 60*time.Second)
    return p, nil
}

Sửa bằng single-flight (in-process với singleflight.Group nếu chỉ một node; distributed lock qua Redis SETNX nếu nhiều node). Ngoài single-flight, kỹ thuật XFetch (Vattani et al., "Optimal Probabilistic Cache Stampede Prevention", 2015) refresh entry sớm hơn TTL với xác suất tăng dần khi tới gần hạn — trải đều tải refresh thay vì dồn vào một tick.

Failure mode 2: stale data vô hạn khi event-based invalidation rớt event. Writer phát event DEL cache:user:123 qua Kafka, cache consumer xoá key. Nếu consumer bị lag, chết, hoặc event bị drop (Kafka retention hết trước khi consumer kịp đọc), key stale mãi mãi vì không có TTL backstop. Rule: event-based invalidation luôn đi kèm TTL — event là fast-path, TTL là safety net. Cấu hình TTL vừa đủ dài để chấp nhận cost, đủ ngắn để bound staleness khi event rớt.

Failure mode 3: thundering herd sau khi flush cache toàn cục. Deploy mới, ai đó chạy FLUSHDB để bust cache. Mọi key biến mất cùng lúc, mọi request tiếp theo miss, origin nhận toàn bộ traffic trực tiếp. Không phải stampede trên một key, mà stampede trên cả cache. Cách xử lý: không flush toàn cục ở giờ cao điểm; nếu cần bust, dùng versioning (đổi prefix key) để cache cũ hết dần theo TTL thay vì biến mất tức thì; hoặc warm cache trước khi cắt traffic.

Failure mode 4: write-through mà không invalidate downstream cache. App có L1 (in-process LRU) và L2 (Redis). Write đi qua và update Redis, nhưng L1 trên từng node vẫn giữ giá trị cũ tới khi TTL local hết. User hit node A thấy dữ liệu mới, hit node B thấy dữ liệu cũ — read-your-write bị phá. Sửa bằng cách hoặc bỏ L1 cho những entity cần consistency, hoặc phát invalidation message qua pub/sub tới tất cả node để mọi L1 evict đồng thời.

Failure mode 5: negative caching quên set TTL ngắn. Cache cả kết quả "không tồn tại" để chống cache penetration, nhưng dùng cùng TTL với hit thật. Khi entity thực sự được tạo sau đó, cache vẫn trả not found cho tới khi TTL hết. TTL của negative entry phải ngắn hơn nhiều so với positive entry.

Cách debug và monitor

Triệu chứng cache stampede: origin QPS/latency đột ngột spike theo bậc thang mỗi khi TTL của key hot hết hạn (đồ thị hình răng cưa); cache hit ratio đột nhiên tụt trong vài giây; DB connection pool queue depth tăng, một số request timeout. Triệu chứng stale data: user report thấy dữ liệu cũ sau khi write; log write path thành công nhưng read path vẫn trả giá trị trước đó; phân tán không đều giữa các node (L1 chưa evict).

Metric cần có:

Cache hit ratio — hit / (hit + miss). Thấp bất thường hoặc dip theo pattern là dấu hiệu invalidation quá aggressive hoặc TTL quá ngắn.
Origin request rate cho các key đi qua cache — spike khi TTL hết là dấu hiệu stampede.
Staleness distribution — nếu event-based, đo độ trễ từ lúc origin commit tới lúc cache reflect (cần timestamp trong payload).
Lock contention cho single-flight — số request phải đợi lock, thời gian đợi trung bình.
Redis INFO stats cho keyspace_hits, keyspace_misses, evicted_keys; redis-cli MONITOR (rất nặng, chỉ dùng ngắn) để xem pattern thực tế.

Trong Prometheus/Grafana, alert khi origin request rate cho một key spike gấp nhiều lần baseline trong vài giây. Rule phòng ngừa: mỗi entry phải có TTL (không entry sống mãi), mọi query nặng đi qua cache phải có single-flight, và mọi event-based invalidation phải có TTL backstop.

Tradeoff

TTL ngắn giảm staleness nhưng tăng origin load (miss nhiều hơn) và tăng nguy cơ stampede. TTL dài giảm origin load nhưng user thấy dữ liệu cũ lâu hơn. Event-based invalidation cho freshness gần realtime nhưng đòi hỏi coupling và infrastructure (message bus, CDC) — mỗi kênh event là một điểm có thể lỗi. Versioning tránh phải xoá gì cả và cho immutable cache entry (dễ CDN), nhưng tốn thêm indirection để nhìn ra version hiện hành, và cache cũ chiếm bộ nhớ tới khi TTL evict.

Single-flight loại bỏ stampede gần như hoàn toàn với cost một round-trip lock; nhược là nếu holder của lock chết mà không release, các request đợi bị block tới khi lock TTL hết — nên lock TTL phải ngắn và có fallback (đợi timeout rồi tự gọi origin). XFetch tránh cần lock, phân tán refresh theo xác suất, nhưng một số request phải chịu latency của refresh sớm dù cache còn hạn.

Rule of thumb: mọi entry cache dùng chung có TTL (không có ngoại lệ); mọi query có thể sinh stampede (query nặng, traffic cao) bọc single-flight; dùng event-based invalidation cho freshness nhưng luôn giữ TTL làm safety net; versioning cho immutable snapshot hoặc khi có CDN.

Câu hỏi phỏng vấn

Cache stampede là gì, xảy ra khi nào, và phòng thế nào trong một hệ có nhiều node cache?

Cache stampede (dogpile / thundering herd) xảy ra khi một key hot vừa expire hoặc bị invalidate; N request đang inflight cùng miss, cùng gọi origin tính lại cùng một giá trị. Origin (thường là DB hoặc service downstream) bất ngờ nhận N lần công việc trùng lặp, connection pool cạn, latency tăng, và có thể sập kéo theo cả service phụ thuộc. Nguyên nhân gốc là cache miss không có coordination giữa các request. Phòng bằng single-flight: chỉ một request được phép gọi origin cho một key tại một thời điểm, các request khác đợi kết quả — in-process dùng singleflight.Group (Go) hoặc tương đương, distributed dùng Redis SET NX EX làm lock với TTL ngắn để tránh deadlock nếu holder chết. Bổ sung XFetch (probabilistic early refresh) để refresh key sớm hơn TTL thật, trải đều tải refresh thay vì dồn vào một tick. Điểm ăn điểm là gọi tên hậu quả production cụ thể (DB connection pool cạn, cascade failure, autoscaler không kịp), phân biệt in-process vs distributed single-flight, và nêu TTL backstop cho event-based invalidation để tránh stale vô hạn khi event rớt.

Hands-on

Dựng một Redis local và một origin giả chậm, tái hiện stampede, đo, sửa bằng single-flight, đo lại.

docker run -d --name redis-stampede -p 6379:6379 redis:7

Tạo file stampede.go:

package main

import (
    "context"
    "fmt"
    "sync"
    "sync/atomic"
    "time"

    "github.com/redis/go-redis/v9"
    "golang.org/x/sync/singleflight"
)

var (
    rdb         = redis.NewClient(&redis.Options{Addr: "localhost:6379"})
    originCalls int64
    sf          singleflight.Group
)

func slowOrigin() ([]byte, error) {
    atomic.AddInt64(&originCalls, 1)
    time.Sleep(200 * time.Millisecond) // giả query DB nặng
    return []byte("payload"), nil
}

func GetNaive(ctx context.Context, key string) ([]byte, error) {
    if v, err := rdb.Get(ctx, key).Bytes(); err == nil {
        return v, nil
    }
    v, err := slowOrigin()
    if err != nil {
        return nil, err
    }
    rdb.Set(ctx, key, v, 2*time.Second)
    return v, nil
}

func GetSingleFlight(ctx context.Context, key string) ([]byte, error) {
    if v, err := rdb.Get(ctx, key).Bytes(); err == nil {
        return v, nil
    }
    v, err, _ := sf.Do(key, func() (interface{}, error) {
        // double-check sau khi giành lock: có thể request khác đã set xong
        if v, err := rdb.Get(ctx, key).Bytes(); err == nil {
            return v, nil
        }
        v, err := slowOrigin()
        if err != nil {
            return nil, err
        }
        rdb.Set(ctx, key, v, 2*time.Second)
        return v, nil
    })
    if err != nil {
        return nil, err
    }
    return v.([]byte), nil
}

func run(name string, fn func(context.Context, string) ([]byte, error)) {
    atomic.StoreInt64(&originCalls, 0)
    rdb.Del(context.Background(), "hot")
    var wg sync.WaitGroup
    start := time.Now()
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fn(context.Background(), "hot")
        }()
    }
    wg.Wait()
    fmt.Printf("%s: 1000 requests, %d origin calls, took %v\n",
        name, atomic.LoadInt64(&originCalls), time.Since(start))
}

func main() {
    run("naive", GetNaive)
    run("single-flight", GetSingleFlight)
}

Chạy:

go mod init stampede-lab
go get github.com/redis/go-redis/v9 golang.org/x/sync/singleflight
go run stampede.go

Output kỳ vọng: bản naive báo cỡ vài trăm origin call cho 1000 request (mỗi request miss trước khi request đầu kịp set) — đúng là stampede. Bản single-flight báo đúng 1 origin call cho 1000 request cùng key. Chạy lại nhiều lần với sleep 2 giữa các lần để ép key expire và xem stampede tái xuất trong bản naive mỗi vòng TTL, trong khi bản single-flight vẫn giữ 1 origin call/vòng.

Bước tiếp: mở rộng bằng Redis SET NX EX để single-flight xuyên node (spawn hai process Go song song, xác nhận chỉ một trong hai gọi slowOrigin khi key expire). Thêm Prometheus counter cho origin_calls_total và cache_hits_total, scrape bằng prometheus local, vẽ chart hình răng cưa của bản naive rồi flat của bản fix — đó là artefact đưa vào postmortem hay design doc thật.

CAP Theorem — Consistency vs Availability

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:27 +0000

CAP: khi network partition xảy ra, chỉ được chọn C hoặc A — không có "cả ba"

CAP theorem là kết quả của Gilbert và Lynch (formal proof năm 2002 cho conjecture Brewer đưa ra ở PODC keynote 2000): một hệ phân tán có shared state không thể đồng thời cung cấp cả linearizable Consistency, Availability (mọi request tới non-failing node đều trả lời không lỗi), và Partition tolerance khi có network partition. Trong thực tế, partition là thứ sẽ xảy ra — TCP retransmit, GC pause dài, switch chết, cross-region link flap — nên P là ràng buộc bắt buộc, không phải lựa chọn. Câu hỏi thật là: khi partition xảy ra, hệ thống hy sinh C hay A? Chọn sai gây ra hai loại incident khác nhau: chọn AP mà dữ liệu cần linearizable dẫn tới double-charge, oversell inventory, split-brain; chọn CP mà dữ liệu chỉ cần eventually consistent dẫn tới downtime không cần thiết, user không đọc được profile của chính mình.

Cơ chế hoạt động

Định nghĩa formal theo Gilbert và Lynch:

Consistency ở đây là linearizability: mọi read sau một write hoàn tất phải thấy giá trị mới (hoặc mới hơn); tồn tại một total order các operation phù hợp với real-time.
Availability: mọi request tới một non-failing node phải nhận response (không timeout, không error).
Partition tolerance: hệ thống tiếp tục hoạt động dù network drop tuỳ ý message giữa các node.

Proof intuition: giả sử có 2 node N1, N2 giữ cùng key x=0. Client ghi x=1 vào N1. Link N1 và N2 đứt. Một client khác đọc x từ N2. Nếu N2 trả về 0 thì không linearizable (mất C). Nếu N2 chờ đến khi thấy được N1 thì mất A. Nếu N2 từ chối phục vụ thì cũng mất A. Không có cách thứ ba.

Trong hệ CP, mỗi write phải qua quorum (Raft, Paxos, ZAB); khi node bị isolate khỏi quorum, nó từ chối phục vụ để giữ linearizability:

// etcd/Raft-style: khi mất quorum, leader step down và write fail
resp, err := kv.Put(ctx, "order/42", "paid")
if err != nil {
    // err là ErrLeaderChanged hoặc context.DeadlineExceeded khi ở minority side
    // client thấy unavailable — đúng contract CP
    return fmt.Errorf("cluster lost quorum: %w", err)
}

Trong hệ AP, node minority vẫn nhận write, gắn version vector / vector clock, đồng bộ sau khi partition heal — có thể conflict và cần resolution (last-write-wins, CRDT, application merge):

# Cassandra: tunable consistency, ONE cho phép write vào node đơn lẻ
session.execute(
    "INSERT INTO cart (user_id, item, qty) VALUES (%s, %s, %s)",
    (user_id, item, qty),
    consistency_level=ConsistencyLevel.ONE,   # AP-style, vẫn ghi khi partition
)
# read sau đó với ONE có thể trả về giá trị cũ ở replica khác

Brewer viết lại năm 2012 (bài "CAP Twelve Years Later" trên IEEE Computer) rằng framing "chọn 2 trong 3" gây hiểu lầm: partition hiếm, và ngay cả một service cũng có thể là CP cho một số operation (thanh toán) và AP cho operation khác (đếm view). CAP là quyết định per-operation, không phải per-system.

Vấn đề gặp trong production

Failure mode 1: giả định là CA (có cả ba) trong một hệ phân tán. Đây là cái bẫy phổ biến nhất. Team dùng Postgres primary cộng read replica, viết code như thể replica luôn có dữ liệu mới nhất:

# SAI — assume read-after-write consistency across replicas
def create_order_and_show(user_id, items):
    order_id = primary.execute("INSERT INTO orders ... RETURNING id", ...)
    # ngay lập tức đọc từ replica để hiển thị
    order = replica.execute("SELECT * FROM orders WHERE id = %s", order_id)
    return order  # None khi replication lag lớn hơn round-trip

Khi replication lag tăng (batch load, network hiccup), order trả về None. Bug này không hiện trong staging vì lag ở đó thường rất nhỏ. Cách sửa: read-your-writes bằng cách đọc lại từ primary sau khi write, hoặc dùng session token / GTID để wait cho replica bắt kịp, hoặc chấp nhận eventual consistency và render optimistic từ input.

# ĐÚNG — đọc lại từ primary trong cùng transaction
def create_order_and_show(user_id, items):
    with primary.transaction() as tx:
        order_id = tx.execute("INSERT INTO orders ... RETURNING id", ...)
        order = tx.execute("SELECT * FROM orders WHERE id = %s", order_id)
    return order

Failure mode 2: chọn AP cho use case cần linearizable. Kinh điển: dùng DynamoDB eventually-consistent read hoặc Cassandra ONE cho counter tồn kho, kết quả oversell. Hai request cùng thấy stock=1, cả hai decrement, cuối cùng stock=-1. Postmortem loại này lặp đi lặp lại trong các báo cáo Jepsen của Kyle Kingsbury: Riak, Cassandra, MongoDB (khi chưa dùng majority write concern và linearizable read concern) đều bị bắt lỗi consistency claim.

// SAI — Cassandra ONE cho inventory decrement, không linearizable
session.execute("UPDATE inventory SET stock = stock - 1 WHERE sku = ?", sku);

// ĐÚNG — dùng lightweight transaction (Paxos) khi cần compare-and-set
session.execute(
    "UPDATE inventory SET stock = ? WHERE sku = ? IF stock = ?",
    newStock, sku, currentStock
);  // trả về applied=false nếu ai đó đã ghi trước — retry

Failure mode 3: chọn CP nhưng không lường được blast radius khi mất quorum. GitHub công bố postmortem về một sự cố cross-DC partition ngắn (dưới một phút) trong tháng 10 năm 2018 khiến MySQL Orchestrator promote replica ở DC khác; khi link phục hồi, có writes ở hai phía — team chọn ưu tiên consistency, dừng writes để reconcile thủ công, chấp nhận degradation kéo dài nhiều giờ. Đó là quyết định CP đúng nhưng cost cao. Nhiều team gặp incident tương tự với Consul, etcd, Zookeeper cluster khi cross-AZ latency spike làm minority partition từ chối phục vụ; nếu health check của app không phân biệt "cluster down" với "cluster unavailable to me", cả service tier bị đánh dấu unhealthy.

Failure mode 4: split-brain do quorum sai. Cluster 2 node với "majority = 1" là công thức split-brain. Khi partition xảy ra, cả hai bên đều nghĩ mình là majority. Đây là lý do Raft/ZAB yêu cầu odd number of voting member và các hệ như etcd, Consul cảnh báo rõ ràng khi số voter chẵn. Với 3 node chịu mất được 1; với 5 node chịu mất được 2 — đó là tradeoff giữa fault tolerance và write latency (quorum càng lớn càng chậm).

Cách debug và monitor

Triệu chứng partition thường bị chẩn đoán nhầm thành "database chậm". Cần phân biệt:

Cluster health metric: etcd_server_has_leader, etcd_server_leader_changes_seen_total, consul.raft.leader.lastContact, MongoDB rs.status() — thay đổi state đột ngột là dấu hiệu leader election, thường do partition.
Replication lag: Postgres pg_stat_replication.replay_lag, MySQL SHOW SLAVE STATUS với Seconds_Behind_Master, Kafka consumer lag. Lag tăng đột ngột trên tất cả replica cùng lúc là network issue, không phải replica chậm.
Quorum loss log: etcd log lost quorum, Zookeeper chuyển LEADING sang LOOKING, Consul raft: heartbeat timeout — những dòng này phải được alert.
Client-side symptom: tỷ lệ context.DeadlineExceeded hoặc NoHostAvailable tăng đột biến trên một subset client (một AZ), trong khi các AZ khác ổn — partial partition.
Consistency test: chạy Jepsen (framework của Kyle Kingsbury) hoặc elle để verify hệ mình dùng có giữ contract quảng cáo không. Nhiều DB đã bị Jepsen bắt lỗi consistency claim, kết quả được document công khai trên jepsen.io.

Rule phòng ngừa:

Không deploy quorum-based cluster với số voter chẵn.
Đặt cluster member ở ít nhất 3 failure domain (AZ) khác nhau; tránh 2-DC setup nếu cần CP.
Health check của app phải phân biệt "tôi không tới được DB" với "DB down globally"; không cascade fail cả tier khi chỉ minority-side unhealthy.
Test partition trong staging bằng tc qdisc (drop packet), iptables -A INPUT -s <peer> -j DROP, hoặc chaos tool (Toxiproxy, Chaos Mesh).

Tradeoff

CP đổi availability lấy correctness: khi partition, minority side từ chối phục vụ, client thấy error, nhưng không bao giờ có hai giá trị mâu thuẫn cùng tồn tại. Phù hợp cho money, inventory, unique constraint (username, order ID), config store, service discovery — nơi trả về stale hoặc conflict tệ hơn trả về error. Cost: write latency cao hơn (phải wait quorum ack), và availability giảm đúng bằng xác suất mất quorum.

AP đổi consistency lấy uptime: mọi replica vẫn nhận request khi partition, đồng bộ sau. Phù hợp cho shopping cart (merge được), social feed, view counter, log ingestion, DNS-style lookup — nơi stale trong vài giây chấp nhận được và downtime tệ hơn. Cost: application phải handle conflict resolution (CRDT, LWW, user chọn merge), read có thể thấy giá trị cũ, monotonic guarantee yếu.

PACELC (Daniel Abadi, 2010) mở rộng CAP: Partition thì chọn A hay C; Else thì chọn Latency hay Consistency. Kể cả khi không có partition, việc chờ replica ack (strong consistency) vẫn thêm latency; nhiều hệ (DynamoDB, Cassandra) chọn EL — hy sinh consistency lấy latency thấp ngay cả trong điều kiện bình thường.

Rule of thumb: quyết định per-operation, không per-system. Money / inventory / unique ID chọn CP path (Raft-backed store, LWT, transactional DB với SERIALIZABLE). Feed / cart / counter / cache chọn AP path (eventual, CRDT hoặc idempotent merge). Không viết code như thể hệ CA tồn tại — nó không tồn tại trong hệ phân tán thật.

Câu hỏi phỏng vấn

CAP theorem nói gì, và tại sao "chọn 2 trong 3" là cách phát biểu sai? Cho một use case cụ thể để minh hoạ khi nào chọn CP, khi nào chọn AP.

CAP (Gilbert và Lynch, 2002, formal hoá conjecture của Brewer 2000) chứng minh rằng trong hệ phân tán có shared state, khi network partition xảy ra không thể đồng thời giữ linearizable consistency và availability (mọi request tới non-failing node đều nhận response). "Chọn 2 trong 3" gây hiểu lầm vì Partition tolerance không phải lựa chọn — network sẽ partition (TCP timeout, GC pause, switch chết); nếu hệ thống không tolerate partition, nó không phải hệ phân tán. Câu hỏi thật là khi partition xảy ra, hy sinh C hay A. Ví dụ: hệ thanh toán và inventory phải CP — dùng Postgres transactional hoặc Raft-backed store (etcd, Spanner-style); khi minority side mất quorum, nó từ chối write, client thấy error, nhưng không có double-charge hay oversell. Ngược lại, shopping cart hoặc social feed nên AP — Cassandra hoặc DynamoDB eventually consistent, merge conflict bằng CRDT hoặc LWW; user vẫn add item được khi partition, đồng bộ sau. Điểm ăn điểm là: nêu Brewer 2012 clarification rằng CAP là quyết định per-operation không per-system; đề cập PACELC — kể cả khi không partition vẫn có tradeoff latency-vs-consistency; kể failure mode thật — giả định CA gây bug read-after-write khi có replication lag, chọn AP cho inventory gây oversell (Jepsen documented cho nhiều DB), chọn CP không lường quorum loss gây incident kiểu GitHub tháng 10 năm 2018 (partition ngắn nhưng downtime dài để reconcile).

Hands-on

Dựng một cluster etcd 3 node local qua Docker để tận mắt quan sát hành vi CP khi partition. Tạo file docker-compose.yml:

version: "3"
services:
  etcd1:
    image: quay.io/coreos/etcd:v3.5.9
    command: >
      etcd --name etcd1
      --initial-advertise-peer-urls http://etcd1:2380
      --listen-peer-urls http://0.0.0.0:2380
      --advertise-client-urls http://etcd1:2379
      --listen-client-urls http://0.0.0.0:2379
      --initial-cluster etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      --initial-cluster-state new
      --initial-cluster-token cap-lab
    ports:
      - "2379:2379"
  etcd2:
    image: quay.io/coreos/etcd:v3.5.9
    command: >
      etcd --name etcd2
      --initial-advertise-peer-urls http://etcd2:2380
      --listen-peer-urls http://0.0.0.0:2380
      --advertise-client-urls http://etcd2:2379
      --listen-client-urls http://0.0.0.0:2379
      --initial-cluster etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      --initial-cluster-state new
      --initial-cluster-token cap-lab
  etcd3:
    image: quay.io/coreos/etcd:v3.5.9
    command: >
      etcd --name etcd3
      --initial-advertise-peer-urls http://etcd3:2380
      --listen-peer-urls http://0.0.0.0:2380
      --advertise-client-urls http://etcd3:2379
      --listen-client-urls http://0.0.0.0:2379
      --initial-cluster etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      --initial-cluster-state new
      --initial-cluster-token cap-lab

Chạy và verify leader:

docker compose up -d
docker compose exec etcd1 etcdctl \
  --endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 \
  endpoint status --write-out=table
docker compose exec etcd1 etcdctl put /order/42 paid
docker compose exec etcd1 etcdctl get /order/42

Tạo partition bằng cách cắt etcd1 khỏi hai node còn lại (etcd1 rơi vào minority):

docker network disconnect cap-lab_default cap-lab-etcd1-1
# hoặc dùng iptables trong container để drop packet tới etcd2, etcd3

Thử write vào minority side — quan sát nó fail sau election timeout:

docker compose exec etcd1 etcdctl --command-timeout=5s put /order/43 attempted
# expected: context deadline exceeded — CP behavior đúng

Thử write vào majority side (etcd2 hoặc etcd3) — vẫn chạy:

docker compose exec etcd2 etcdctl put /order/43 paid
docker compose exec etcd2 etcdctl get /order/43

Heal partition và verify etcd1 catch up:

docker network connect cap-lab_default cap-lab-etcd1-1
sleep 5
docker compose exec etcd1 etcdctl get /order/43   # thấy giá trị từ majority

Sau đó lặp lại thí nghiệm với một AP store (Cassandra 3-node) để so sánh. Dùng docker compose với image cassandra:4.1, tạo keyspace với replication_factor = 3, ghi bằng CONSISTENCY ONE khi partition, quan sát mỗi node có thể trả về giá trị khác nhau, rồi resolve sau khi heal. So sánh hai hành vi trên cùng một scenario: etcd từ chối write ở minority (CP), Cassandra chấp nhận write ở mọi node (AP) — chính là tradeoff C-vs-A trong thực tế.

Redundancy & Replication — Data Redundancy

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:23 +0000

Data redundancy: một node lỗi là mất dữ liệu, và replica async không cứu được nếu không ai theo dõi lag

Data redundancy là việc giữ nhiều bản copy của cùng một dataset trên các node khác nhau để khi một node chết, dataset không đi theo nó. Cơ chế thực thi phổ biến nhất là replication: một node là source-of-truth (primary/leader), các node khác nhận và apply lại các thay đổi. Nghe đơn giản, nhưng phần lớn incident mất dữ liệu ở database không đến từ "chưa có replica" mà từ "có replica nhưng không sync kịp lúc primary chết", hoặc "replica đã broken từ lâu mà không ai biết vì không có alert trên replication lag". Postmortem của GitLab.com tháng 1/2017 là ví dụ điển hình: một engineer xoá nhầm data directory trên primary, mọi replica đã ngừng streaming từ trước, và các backup channel khác đều hỏng — dữ liệu vài giờ cuối mất hẳn dù về danh nghĩa hệ thống "có replica".

Cơ chế hoạt động

Ở database quan hệ (Postgres, MySQL), replication chạy trên write-ahead log (WAL / binlog): mọi thay đổi trước khi vào table file đều được append vào một file log tuần tự; replica kết nối tới primary, stream các WAL record đó, và apply lại y hệt vào bản data local. Vì WAL là physical/logical record của mọi thay đổi đã commit, replica hội tụ về cùng state với primary — miễn là nó theo kịp.

Điểm quyết định là thời điểm primary trả "commit ok" về client:

Async replication — primary flush WAL local rồi trả ngay. WAL được đẩy sang replica ở background. Nhanh, nhưng nếu primary chết trong khoảng "đã commit local, chưa gửi sang replica", các transaction đó không tồn tại trên replica.
Sync replication — primary phải chờ ít nhất một replica xác nhận đã nhận (hoặc đã flush, hoặc đã apply) WAL rồi mới trả về client. Không mất transaction đã ack, đổi lại latency mỗi commit tăng theo RTT tới replica chậm nhất, và nếu replica sync down thì primary có thể block write.
Quorum-based — thay vì phân biệt primary/replica cứng, N replica tham gia; một write chỉ coi là committed khi được W trong N replica ack, một read cần R replica trả để lấy giá trị mới. Với W + R > N, mọi read đảm bảo thấy write đã committed. Dynamo/Cassandra dùng tunable quorum ở tầng client; etcd/Consul/ZooKeeper dùng Raft/Paxos ép quorum majority ở tầng consensus; Kafka dùng ISR (in-sync replicas) + acks=all + min.insync.replicas.

Postgres cho phép chọn strictness qua synchronous_commit và synchronous_standby_names:

# postgresql.conf trên primary
wal_level = replica
max_wal_senders = 10
synchronous_standby_names = 'ANY 1 (standby1, standby2)'  # cần 1 trong 2 ack
synchronous_commit = on   # 'on' = chờ remote flush WAL; 'remote_apply' = chờ apply xong

Với config trên, một COMMIT chỉ trả về client khi ít nhất một trong hai standby đã fsync WAL. Nếu đổi thành synchronous_commit = off, primary trả ngay cả trước khi fsync local — hiệu năng cao nhất, rủi ro mất vài trăm ms transaction gần nhất khi primary crash. MySQL có mô hình tương tự: async là mặc định, semi-sync qua plugin rpl_semi_sync_source chờ replica ack đã ghi relay log (chưa apply), Group Replication dùng consensus theo Paxos-variant.

Vấn đề gặp trong production

Failure mode 1: async replication + failover = mất transaction đã ack. Primary chạy async, replica trễ vài giây. Primary crash, orchestrator promote replica; các transaction commit trong khoảng "đã ack cho client, chưa stream sang replica" biến mất khỏi hệ thống mới. Client tưởng đơn hàng đã ghi (đã nhận 200 OK), sau failover query lại thì không thấy. Đây là RPO ≠ 0 — bug nghiệp vụ, không phải bug code. Kịch bản GitHub tháng 10/2018 (postmortem chính thức trên blog GitHub Engineering) đúng dạng này ở quy mô cross-region: một partition mạng ngắn kích hoạt failover ở region khác, và việc reconcile hai bản sau đó mất hàng giờ vì trạng thái đã diverge.

Fix ở tầng config, không phải code:

# Sai: async, chấp nhận mất write khi primary chết
synchronous_commit = local
synchronous_standby_names = ''

# Đúng cho data không được phép mất (đơn hàng, thanh toán):
synchronous_commit = on
synchronous_standby_names = 'ANY 1 (standby1, standby2)'  # ít nhất 1 remote flush

Với ANY 1 (…), chỉ cần một trong nhiều standby còn sống là commit vẫn tiến; primary không bị block chỉ vì một standby chậm. Đừng dùng FIRST 1 (standby1) với chỉ một replica — replica đó down là toàn bộ write block.

Failure mode 2: replica đã ngừng streaming mà không ai biết. Đây là lỗi từ postmortem GitLab.com: replication đã broken (do WAL retention hết, replica bị bỏ xa), nhưng vì không có alert trên replication lag > threshold nên team tưởng replica đang healthy. Khi cần fallback thì replica hoặc quá cũ, hoặc đã tự stop hẳn. Nguyên nhân kỹ thuật thường gặp: primary purge WAL segment cũ trước khi replica kịp fetch (Postgres không có replication slot, hoặc slot bị drop; MySQL binlog expire_logs_days quá ngắn). Fix: bật replication slot (primary_slot_name trên standby + pg_create_physical_replication_slot trên primary) để primary giữ WAL đến khi replica đọc xong, KÈM alert khi slot lag vượt ngưỡng — vì slot cũng có tác dụng phụ: replica chết → WAL tích dồn → đầy disk primary.

Failure mode 3: semi-sync degrade thành async âm thầm. MySQL semi-sync có timeout (rpl_semi_sync_source_timeout): nếu không replica nào ack trong khoảng đó, primary fallback sang async để không block write. Đây là hành vi thiết kế — nhưng nếu network flap kéo dài, cluster chạy async suốt mà dashboard vẫn báo "semi-sync enabled". Client tưởng đang được bảo vệ. Postgres tương đương: synchronous_commit = on với synchronous_standby_names — nếu tất cả standby down, primary block write (an toàn hơn nhưng gây downtime); một số team hạ thành local để tránh block, và quay lại failure mode 1. Không có lựa chọn miễn phí; phải hiểu config đang trade cái gì.

Failure mode 4: quorum sai — acks=1 hoặc min.insync.replicas=1. Kafka topic replication factor 3 nhưng producer acks=1 chỉ cần leader ack; leader crash trước khi replicate sang follower là mất message đã ack. Fix chuẩn: acks=all + min.insync.replicas=2 (với RF=3) — producer nhận NotEnoughReplicas exception khi số ISR tụt xuống dưới 2, và có thể chọn fail-fast thay vì ghi vào cluster đã giảm redundancy. Đây là mặc định khuyến nghị trong Kafka documentation cho durability.

Failure mode 5: split-brain khi failover không dùng fencing. Primary bị coi là chết vì network partition, orchestrator promote standby thành primary mới, client mới ghi vào đó. Nhưng primary cũ chưa thực sự chết — chỉ mất kết nối tới orchestrator. Client cũ vẫn ghi vào primary cũ. Hai bản data diverge, không merge tự động được. Cách phòng: STONITH ("shoot the other node in the head") hoặc fencing bằng cách cắt VIP/DNS/network trước khi promote; hoặc dùng consensus-based system (etcd/Consul làm lease store) để chỉ một primary có lease tại một thời điểm. Async replication làm tình huống này tệ hơn hẳn sync, vì tại thời điểm split hai bản đã có khác biệt.

Cách debug và monitor

Triệu chứng replication lag: sau khi ghi vào primary, read từ replica trong vài giây tiếp theo không thấy record (read-your-writes fail); sau failover, một số record "biến mất"; trên dashboard, khoảng cách LSN giữa primary và replica tăng dần và không giảm.

Metric bắt buộc (Postgres, đọc từ pg_stat_replication trên primary):

write_lag — khoảng thời gian từ khi primary flush WAL local đến khi standby ack đã nhận. Đo lag mạng + xử lý của walreceiver.
flush_lag — thêm thời gian standby fsync WAL xuống disk local. Đây là mốc synchronous_commit = on chờ.
replay_lag — thêm thời gian standby thực sự apply xong WAL vào data file. Đây là mốc quyết định "read từ replica có thấy write mới không".
pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) — bytes chưa replay, đơn vị byte thay vì thời gian. Đọc cùng với thời gian để phát hiện replica đã stall (lsn diff tăng mà replay không đuổi kịp).
pg_replication_slots.active — slot có đang được stream không. false kéo dài + restart_lsn giữ nguyên = replica đã disconnect, WAL đang tích trên primary.

MySQL tương đương: SHOW REPLICA STATUS (hoặc SHOW SLAVE STATUS bản cũ) cho Seconds_Behind_Source, Replica_IO_Running, Replica_SQL_Running, và Retrieved_Gtid_Set vs Executed_Gtid_Set. Chú ý Seconds_Behind_Source chỉ là ước lượng: nếu IO thread đứt, giá trị vẫn có thể là 0 vì SQL thread đang apply relay log đã có — check cả Replica_IO_Running=Yes.

Kafka: kafka-consumer-groups.sh --describe cho LAG per partition, JMX metric UnderReplicatedPartitions cho topic có ISR < RF, kafka-topics.sh --describe --under-min-isr-partitions để list topic đang không đủ quorum.

Alert cần có: (1) lag thời gian vượt ngưỡng SLA (vd vài giây với read-heavy service, hàng chục giây với reporting replica); (2) lag byte tăng đơn điệu không giảm trong X phút = replica đang thua tốc độ ghi; (3) replication slot active=false quá vài phút; (4) UnderReplicatedPartitions > 0 với Kafka; (5) min.insync.replicas không đạt.

Rule phòng: không bao giờ dùng replica để chống mất dữ liệu mà không có alert lag và không có backup riêng — replica là HA, không phải backup. Replica sao chép cả lệnh DROP TABLE nhanh chóng.

Tradeoff

Sync replication cho RPO = 0 (không mất transaction đã ack) đổi lại: mỗi write phải chờ RTT tới replica sync gần nhất, throughput commit giảm, và nếu tất cả standby sync đều down thì primary block write — HA của availability giảm để đổi lấy HA của data. Async cho latency thấp và write không phụ thuộc standby, đổi lại RPO > 0 và replica có thể trễ hàng chục giây dưới tải lớn, gây stale read và mất write khi failover. Quorum majority (Raft/Paxos, hoặc W+R>N) cho balance: chấp nhận latency của N/2+1 replica gần nhất chứ không phải toàn bộ, và tự động chịu được N/2 node chết mà không cần failover thủ công — đổi lại complexity vận hành cao hơn và write latency đều bị ràng buộc bởi replica chậm thứ N/2+1. Càng nhiều replica càng an toàn dữ liệu và scale read tốt hơn, nhưng chi phí storage + network + độ khó vận hành tăng tuyến tính.

Rule of thumb: data không được phép mất (payment, order, user identity) dùng sync (hoặc quorum majority) với ít nhất 2 replica remote-flush, alert khi lag > vài giây; data chấp nhận RPO vài giây (analytics, session, cache) dùng async với 1–2 replica, alert khi lag > 30 giây; luôn có backup off-cluster ngoài replica — replica sao chép cả lỗi người dùng.

Câu hỏi phỏng vấn

Sync và async replication khác gì nhau, và khi nào chọn cái nào?

Async: primary commit local xong trả về client ngay, WAL/binlog stream sang replica ở background. Nhanh, không phụ thuộc replica còn sống, throughput cao, nhưng RPO > 0 — nếu primary chết trong khoảng chưa kịp stream, các transaction đã ack cho client biến mất khỏi hệ thống sau failover. Sync: primary chờ ít nhất một replica ack đã flush (hoặc apply) WAL rồi mới trả về client. RPO = 0 cho transaction đã ack, nhưng latency mỗi commit tăng theo RTT tới replica sync chậm nhất, và nếu tất cả replica sync down thì primary block write (Postgres) hoặc âm thầm degrade về async (MySQL semi-sync với timeout). Chọn theo cost of losing data: payment/order dùng sync với synchronous_standby_names = 'ANY 1 (…)' và tối thiểu 2 standby (để một cái down không block write); analytics/session/cache dùng async vì mất vài giây record không sập nghiệp vụ. Điểm ăn điểm là nêu hai failure mode production: (1) async + failover = mất write đã ack (kịch bản dạng GitHub 2018 khi network partition kích hoạt promote replica đang trễ); (2) replica ngừng streaming âm thầm (GitLab.com 2017) vì không có alert trên replication lag và slot inactive, dẫn tới "có replica trên giấy nhưng không có replica lúc cần" — nên monitor pg_stat_replication (write/flush/replay lag), Kafka UnderReplicatedPartitions, và luôn có backup off-cluster riêng vì replica sao chép cả DROP TABLE.

Hands-on

Dựng một cluster Postgres primary + streaming standby trên Docker, tạo transaction, đo lag, kill primary và promote standby, so sánh khi chạy async vs sync.

mkdir -p pg-repl-lab && cd pg-repl-lab
docker network create pgnet

# --- primary ---
docker run -d --name pg-primary --network pgnet \
  -e POSTGRES_PASSWORD=pw \
  -e POSTGRES_DB=app \
  -p 5432:5432 \
  postgres:16 \
  -c wal_level=replica \
  -c max_wal_senders=10 \
  -c hot_standby=on \
  -c synchronous_commit=on

sleep 5
# Tạo replication user + slot trên primary
docker exec -u postgres pg-primary psql -c \
  "CREATE ROLE repl WITH REPLICATION LOGIN PASSWORD 'rp';"
docker exec -u postgres pg-primary psql -c \
  "SELECT pg_create_physical_replication_slot('standby1');"
docker exec -u postgres pg-primary bash -c \
  "echo 'host replication repl 0.0.0.0/0 md5' >> /var/lib/postgresql/data/pg_hba.conf"
docker exec -u postgres pg-primary psql -c "SELECT pg_reload_conf();"

Bootstrap standby bằng pg_basebackup rồi start ở hot-standby mode (dùng volume riêng cho từng node ở lab thật):

docker volume create pgstandby
docker run --rm --network pgnet -v pgstandby:/var/lib/postgresql/data \
  -e PGPASSWORD=rp postgres:16 \
  pg_basebackup -h pg-primary -U repl -D /var/lib/postgresql/data \
    -Fp -Xs -R -S standby1 -c fast

docker run -d --name pg-standby --network pgnet -p 5433:5432 \
  -v pgstandby:/var/lib/postgresql/data \
  postgres:16 -c hot_standby=on

Kiểm tra replication đang stream:

docker exec -u postgres pg-primary psql -c \
  "SELECT application_name, state, write_lag, flush_lag, replay_lag,
          pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
   FROM pg_stat_replication;"
# kỳ vọng: state='streaming', các cột lag rất nhỏ hoặc NULL

Bắn tải write để tạo lag:

docker exec -u postgres pg-primary psql -d app -c \
  "CREATE TABLE t(id serial primary key, v text, ts timestamptz default now());"

docker exec -u postgres pg-primary psql -d app -c \
  "INSERT INTO t(v) SELECT md5(g::text) FROM generate_series(1,100000) g;"

# đọc từ standby
docker exec -u postgres pg-standby psql -d app -c "SELECT count(*) FROM t;"
# so sánh với primary — khi lag còn tồn tại, hai giá trị khác nhau trong khoảnh khắc

Bật sync mode và quan sát khác biệt: sửa postgresql.conf trên primary thêm synchronous_standby_names = 'ANY 1 (walreceiver)', reload, rồi stop standby (docker stop pg-standby) và thử insert. Với synchronous_commit=on và không còn standby ack, INSERT sẽ hang cho tới khi standby quay lại — đúng behavior "bảo vệ dữ liệu, hy sinh availability write".

Test failover và đo RPO thực tế:

# quay lại async để dễ tái hiện data loss
docker exec -u postgres pg-primary psql -c \
  "ALTER SYSTEM SET synchronous_commit = 'local'; SELECT pg_reload_conf();"

# ép lag lớn: pause standby, insert nhiều trên primary
docker pause pg-standby
docker exec -u postgres pg-primary psql -d app -c \
  "INSERT INTO t(v) SELECT 'lost-' || g FROM generate_series(1,5000) g;"

# kill primary khi standby vẫn đang pause
docker stop pg-primary
docker unpause pg-standby

# promote standby thành primary mới
docker exec -u postgres pg-standby psql -c "SELECT pg_promote();"
docker exec -u postgres pg-standby psql -d app -c \
  "SELECT count(*) FROM t WHERE v LIKE 'lost-%';"
# kỳ vọng: < 5000 — số row thiếu chính là RPO cụ thể tại thời điểm crash

Lặp lại với synchronous_commit = on + synchronous_standby_names set — thao tác INSERT khi standby paused sẽ block thay vì thành công, tức là không có write nào bị mất vì không có write nào được ack. Đây là bằng chứng trực tiếp cho tradeoff sync vs async.

Cuối cùng, mô phỏng "replica chết âm thầm giữ WAL": pause standby dài, chạy loop insert liên tục vào primary, và quan sát pg_wal_lsn_diff cùng dung lượng directory pg_wal/ trên primary tăng đều. Đây là failure mode "slot giữ WAL cho replica chết" — nếu để lâu primary sẽ hết disk và dừng nhận write. Alert cần bắt tình huống này ở giai đoạn lag_bytes vượt ngưỡng, không đợi tới lúc disk full.

Load Balancing — Traffic Distribution

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:20 +0000

Traffic distribution: vì sao thuật toán chỉ là phần dễ, health check mới quyết định service có sập hay không

Load balancer (LB) đứng trước một pool backend và quyết định request kế tiếp sẽ đi tới instance nào. Về lý thuyết nó chỉ là một router có thuật toán chọn; trong thực tế nó là điểm sống chết của service, vì lỗi phổ biến nhất không phải "thuật toán phân tải chưa tối ưu" mà là LB tiếp tục route traffic vào một backend đã chết — process crash, port còn mở, hoặc app trả 500 mà LB không biết. Kết quả là một phần request (1/N nếu round-robin) đều 5xx trong khi dashboard vẫn xanh vì "backend còn listen". Bài này nói về cơ chế phân tải và cái quan trọng hơn: health check phải sâu tới đâu, và LB tự nó redundant thế nào.

Cơ chế hoạt động

Có hai tầng LB phổ biến. L4 (TCP/UDP) chỉ nhìn 5-tuple (src IP, src port, dst IP, dst port, protocol) và forward gói — nhanh, protocol-agnostic, nhưng không biết đây là HTTP GET hay POST. Ví dụ: AWS NLB, HAProxy ở mode tcp, IPVS, LVS. L7 (HTTP/gRPC) parse request, biết path/header/method, có thể route theo Host, rewrite path, retry idempotent request, terminate TLS — chi phí là thêm latency và CPU per request. Ví dụ: nginx, HAProxy ở mode http, Envoy, AWS ALB.

Thuật toán chọn backend, chọn theo workload:

round-robin — luân phiên. Đơn giản, tốt khi request đồng đều về chi phí.
weighted round-robin — mỗi backend một weight; instance to hơn nhận nhiều hơn.
least-connections — chọn backend đang có ít active connection nhất. Tốt khi request có thời gian xử lý khác nhau nhiều (long-polling, streaming, upload).
IP hash / consistent hash — hash một key (client IP, session ID, cache key) rồi map sang backend. Bắt buộc khi cần session affinity hoặc cache locality. Consistent hashing (Ketama, Maglev) hạn chế reshuffle khi thêm/bớt node — chỉ khoảng 1/N key phải remap thay vì gần hết.
power-of-two-choices / least-request — chọn ngẫu nhiên 2 backend, lấy cái ít load hơn. Envoy dùng mặc định vì tránh được "herding" của least-connections mà không cần global state.

Một config nginx L7 điển hình, có health check và timeout — không phải toy example:

upstream api_backend {
    least_conn;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=10s;
    server 10.0.1.13:8080 max_fails=3 fail_timeout=10s backup;
    keepalive 64;
}

server {
    listen 443 ssl http2;
    location / {
        proxy_pass http://api_backend;
        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_next_upstream_tries 2;
        proxy_connect_timeout 2s;
        proxy_read_timeout    10s;
        proxy_http_version    1.1;
        proxy_set_header      Connection "";
    }
}

Đây là passive health check (nginx OSS): sau max_fails lỗi trong fail_timeout, backend bị đánh dấu down và bỏ khỏi pool trong fail_timeout giây. HAProxy hoặc nginx Plus có active health check — LB tự chủ động gõ một endpoint (option httpchk GET /healthz trong HAProxy) theo interval, không cần chờ traffic thật để phát hiện chết.

Health check phải phân biệt hai mức: liveness (process còn chạy không) và readiness (process có phục vụ được không — DB reachable, cache warm, migration xong). Route traffic dựa trên readiness. Kubernetes phân tách rõ hai loại; nếu LB chỉ ping TCP port thì đó là liveness giả — port mở không có nghĩa là app hoạt động.

Vấn đề gặp trong production

Failure mode 1: không có health check, hoặc chỉ check TCP. LB thấy port 8080 accept SYN nên coi backend healthy, trong khi app đã deadlock hoặc mất kết nối DB. Cứ 1/N request rơi vào node đó là 500. Client retry thì retry qua cùng LB, có thể lại rơi vào cùng backend nếu sticky session. Đây là kịch bản "route traffic tới backend chết" — LB phân tải thành công 100%, nhưng vào cả xác.

Sai:

upstream api {
    server 10.0.1.11:8080;   # không max_fails, không active check
    server 10.0.1.12:8080;   # backend crash -> nginx vẫn gửi
}

Đúng: bật passive check tối thiểu (như block ở trên), và ở tầng app expose /healthz kiểm tra dependency thật:

// Express readiness endpoint — trả 200 CHỈ khi thực sự phục vụ được
app.get('/healthz', async (req, res) => {
  try {
    await db.query('SELECT 1')                // DB pool alive?
    await redis.ping()                         // cache reachable?
    if (!migrationsDone) throw new Error('warming up')
    res.status(200).send('ok')
  } catch (e) {
    res.status(503).send('not ready')          // LB sẽ pull khỏi pool
  }
})

Rồi cấu hình LB gõ endpoint này (HAProxy option httpchk GET /healthz với http-check expect status 200, hoặc ALB target group health check path /healthz). Kết quả: node mất DB tự động drain khỏi pool trong vài giây thay vì cả đêm.

Failure mode 2: health check quá nông hoặc quá sâu. Nông (chỉ TCP, hoặc /healthz trả 200 bất kể) route vào backend chết như trên. Sâu quá — /healthz check cả chain DB + Redis + downstream service — thì một service downstream flap sẽ làm toàn bộ backend đồng loạt bị mark down, LB không còn node nào healthy, cluster tự sập dù backend vẫn chạy. Đây là "correlated failure": health check gộp dependency chung. Rule thực tế: readiness chỉ check dependency critical trực tiếp, không transitive. Nếu Redis chỉ dùng cache-aside có thể fallback, đừng đưa vào readiness.

Failure mode 3: LB không biết backend restart chậm (slow start). Container mới join pool nhận full traffic ngay khi health check pass, nhưng JVM chưa warm, JIT chưa optimize, cache chưa fill — node mới trả latency cao, error nhiều, có thể oscillate down/up. HAProxy có slowstart để ramp weight từ 0 lên full trong khoảng thời gian cấu hình; nginx Plus và Envoy có tương đương. Không dùng slow-start — mỗi deploy có một đợt lag spike.

Failure mode 4: sticky session + auto-scaling. Bật ip_hash hoặc cookie-based affinity để giữ session ở một backend, rồi scale-out. Node mới join nhưng không nhận traffic mới (hash key đã map hết vào node cũ), trong khi node cũ oversubscribed. Khi scale-in, một loạt session mất. Fix: đưa session state ra ngoài (Redis, DB) để LB tự do rebalance; nếu bắt buộc affinity vì cache locality, dùng consistent hashing thay vì modulo, và chấp nhận phải rehash một phần khi topology đổi.

Failure mode 5: LB là SPOF. Một instance HAProxy/nginx bare-metal đứng trước 20 backend — nếu nó chết, mất tất. Cách xử lý thực tế: hai LB active-passive với keepalived/VRRP chia sẻ virtual IP, hoặc active-active sau một anycast IP / cloud LB (ELB, GCLB) là managed và tự HA qua nhiều AZ. Đừng chỉ redundant backend mà quên chính lớp balancer.

Failure mode 6: retry storm khuếch đại lỗi. LB set proxy_next_upstream error timeout để failover request khi backend lỗi. Nếu tất cả backend đang overloaded và trả 503, LB retry sang backend khác cũng 503, cuối cùng mỗi request gốc thành N request nội bộ — traffic tự nhân N, backend càng chết nhanh. Cách hạn: giới hạn proxy_next_upstream_tries, chỉ retry trên lỗi idempotent (không retry POST), và kết hợp với circuit breaker ở tầng app (Envoy có outlier detection tự eject node lỗi liên tục ra khỏi pool).

Cách debug và monitor

Triệu chứng "LB đang route vào xác": error rate 5xx tăng nhưng chỉ ở tỷ lệ 1/N (N = số backend), latency phân bố bimodal — phần lớn request nhanh, một cụm timeout đúng bằng proxy_read_timeout. Nếu nhìn tổng thể có thể trông như "spike nhẹ", nhưng breakdown per-upstream sẽ lộ ra một backend gánh 100% lỗi.

Metric bắt buộc, đo theo per-backend (không phải chỉ tổng):

Backend health status — up/down state. HAProxy phơi qua stats socket (echo "show stat" | socat stdio /var/run/haproxy.sock) và trang stats HTTP; Envoy phơi qua /clusters admin endpoint và Prometheus envoy_cluster_membership_healthy; ALB/NLB có CloudWatch metric HealthyHostCount và UnHealthyHostCount per target group.
Request distribution — request per second per backend. Skew lớn (một node nhận gấp mấy lần các node khác dù cùng weight) là dấu hiệu sticky-session bám cứng, hoặc một node bị mark down mà không ai để ý.
Per-upstream latency và error rate — nginx log $upstream_addr, $upstream_status, $upstream_response_time; HAProxy có %si (server IP) và %Tr (response time) trong log format. Không có phần upstream_* trong log thì gần như không debug được LB.
Active connections per backend — với least-connections cần metric này để verify LB đang thấy đúng con số; nếu LB nghĩ node A có nhiều conn trong khi thực tế app A idle, có thể là connection leak trong LB hoặc client giữ keepalive không đóng.
Health check success rate — flap rate cao (node lên xuống liên tục) tệ hơn hẳn "down thẳng"; thường do check interval quá ngắn hoặc threshold quá nhạy.

Tool để đọc trực tiếp: HAProxy stats page hoặc haproxy_exporter cho Prometheus; nginx stub_status module + nginx-prometheus-exporter; Envoy admin /stats/prometheus; AWS Console — target group — Targets tab để xem lý do unhealthy (thường là "Health checks failed with these codes: [502]"); kubectl describe endpoints <svc> để xem endpoint controller đã eject pod chưa; kubectl get endpointslices cho cluster mới hơn.

Rule phòng ngừa: (1) mọi backend phải expose /healthz khác / — không dùng root làm health check, vì root có thể được cache/rewrite ngoài ý muốn; (2) alert khi bất kỳ backend nào ở trạng thái down quá vài phút; (3) alert khi distribution skew (max/min RPS per backend) vượt ngưỡng trong pool được cho là đồng nhất; (4) trong staging phải kill -9 một backend và verify LB drain đúng — không chỉ đọc config.

Tradeoff

L4 cho throughput cao và latency thấp (không parse payload, không terminate TLS), đổi lại mất khả năng route theo path/header, không retry được idempotent, khó observe. L7 cho routing thông minh, retry, TLS termination, WAF, đổi lại thêm chi phí CPU và một chút latency per request. Chọn theo protocol: gRPC/HTTP nên L7 để hưởng retry và load-aware routing; MySQL/Postgres/Kafka/Redis nên L4 vì L7 không hiểu protocol nội bộ. Health check nông (TCP) rẻ nhưng không phát hiện app dead-but-listening; health check sâu (đầy đủ dependency) bắt được nhiều lỗi hơn nhưng dễ tạo correlated failure khi một dependency phụ flap. Round-robin đơn giản, không cần state; least-connections xử lý tốt workload có phương sai, đổi lại phải track connection count (LB cần thấy chính xác, khó khi có nhiều LB instance không share state). Consistent hashing tối ưu cache locality, đổi lại phân bố không đều bằng round-robin. LB tự nó phân tải và HA cho backend, nhưng chính nó là chokepoint — phải HA bằng redundant LB + VRRP/anycast, nếu không thì chỉ đang dời SPOF từ backend sang LB.

Rule of thumb: L7 cho HTTP-facing, L4 cho protocol khác; least-connections (hoặc power-of-two-choices) mặc định trừ khi có lý do cụ thể chọn khác; active health check trên /readyz chỉ chứa dependency critical trực tiếp; luôn có ít nhất 2 LB instance chia virtual IP hoặc dùng managed LB.

Câu hỏi phỏng vấn

Thiết kế load balancer cho một API service 3 instance. Nên dùng thuật toán nào, health check ra sao, và làm sao để chính LB không thành single point of failure?

Chọn L7 vì đây là HTTP API — cần retry idempotent request, terminate TLS, và log per-upstream để debug. Thuật toán mặc định least-connections (hoặc power-of-two-choices nếu dùng Envoy) vì request API thường có phương sai thời gian xử lý; round-robin chỉ tối ưu khi request đồng đều. Health check phải là active, gõ /readyz theo interval vài giây, threshold vài lần fail liên tiếp trước khi mark down và vài lần pass liên tiếp trước khi mark up (tránh flap). /readyz chỉ trả 200 khi app thật sự phục vụ được — kiểm DB connection pool và cache reachable, nhưng không transitive tới các downstream service không critical, tránh correlated failure kéo cả pool xuống khi một dependency phụ flap. Cấu hình slow-start để node mới ramp weight từ 0 tránh cold-start lag, giới hạn next_upstream_tries và chỉ retry lỗi idempotent để không tạo retry storm. Chính LB phải redundant: hai instance HAProxy/nginx active-passive share virtual IP qua keepalived/VRRP, hoặc dùng cloud managed LB (ALB, GCLB) tự HA qua nhiều AZ. Điểm ăn điểm là chỉ ra hai failure mode production thật: (1) health check quá nông nghĩa là LB vẫn route vào backend đã crash-nhưng-port-mở, biểu hiện là 1/N request 5xx dù dashboard tổng thể nhìn "gần OK"; (2) LB tự nó là chokepoint, redundant backend mà không redundant LB thì chỉ dời SPOF một tầng — phải giải quyết cả hai mới coi là HA.

Hands-on

Dựng một pool 3 backend + 1 HAProxy trên Docker, giết một backend, quan sát LB drain, rồi so sánh với config không có health check để thấy failure mode "route vào xác".

Tạo backend Node.js đơn giản có /healthz điều khiển được:

mkdir -p lb-lab && cd lb-lab
cat > server.js <<'JS'
const http = require('http');
const id = process.env.ID || 'x';
let healthy = true;
http.createServer((req, res) => {
  if (req.url === '/healthz') {
    res.writeHead(healthy ? 200 : 503).end(healthy ? 'ok' : 'down');
  } else if (req.url === '/kill') {
    healthy = false; res.end('marked unhealthy');
  } else if (req.url === '/revive') {
    healthy = true; res.end('back');
  } else {
    res.end('hello from ' + id + '\n');
  }
}).listen(8080, () => console.log('backend ' + id + ' on 8080'));
JS

cat > Dockerfile <<'DOCKER'
FROM node:20-alpine
WORKDIR /app
COPY server.js .
CMD ["node", "server.js"]
DOCKER

docker build -t lb-backend .

Tạo HAProxy config có active health check:

cat > haproxy.cfg <<'CFG'
global
    log stdout format raw local0
defaults
    mode http
    timeout connect 2s
    timeout client  10s
    timeout server  10s
    option httplog
frontend fe
    bind *:80
    default_backend be
backend be
    balance leastconn
    option httpchk GET /healthz
    http-check expect status 200
    default-server inter 2s fall 2 rise 2 slowstart 10s
    server b1 b1:8080 check
    server b2 b2:8080 check
    server b3 b3:8080 check
frontend stats
    bind *:8404
    stats enable
    stats uri /
CFG

Chạy pool:

docker network create lbnet
docker run -d --name b1 --network lbnet -e ID=b1 lb-backend
docker run -d --name b2 --network lbnet -e ID=b2 lb-backend
docker run -d --name b3 --network lbnet -e ID=b3 lb-backend
docker run -d --name lb --network lbnet -p 8080:80 -p 8404:8404 \
  -v "$PWD/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro" \
  haproxy:2.8

Bắn traffic đều và xem phân phối:

for i in $(seq 1 30); do curl -s localhost:8080/; done | sort | uniq -c
# kỳ vọng: xấp xỉ 10 request mỗi backend

Mở stats page ở http://localhost:8404/ — xem cột Status (UP/DOWN), LastChk, Sessions.

Giờ ép một backend "chết ở tầng app" (port vẫn mở, /healthz trả 503):

docker exec b2 wget -qO- http://localhost:8080/kill
# đợi vài giây cho HAProxy fail 2 check liên tiếp
for i in $(seq 1 30); do curl -s localhost:8080/; done | sort | uniq -c
# kỳ vọng: b2 biến mất, b1 và b3 chia đôi traffic; không có 5xx

So sánh với version không có health check: sửa haproxy.cfg bỏ option httpchk, http-check expect, và check ở cuối mỗi dòng server, rồi docker restart lb. Kill lại b2 và bắn traffic:

docker exec b2 wget -qO- http://localhost:8080/kill
for i in $(seq 1 30); do curl -s -o /dev/null -w "%{http_code}\n" localhost:8080/; done | sort | uniq -c
# kỳ vọng: ~1/3 request trả 503 (rơi vào b2), 2/3 trả 200

Đây là chính kịch bản "route traffic tới backend chết" — LB phân tải thành công, nhưng vào cả xác. Bật lại health check và verify curl không còn thấy 503 nào.

Cuối cùng, dựng LB HA để thấy tại sao phải redundant chính LB: chạy hai container HAProxy giống nhau (lb1, lb2), đặt một tầng phía trước (một nginx tối giản round-robin giữa lb1:80 và lb2:80, hoặc trên máy thật là keepalived share virtual IP). Kill lb1, verify traffic vẫn qua lb2. Đó là mô hình tối thiểu để LB không thành SPOF; production nên dùng managed LB (ALB/NLB/GCLB) để không phải tự vận hành lớp này.

SARGability — Index-friendly SQL

Nghề không nhiều chẳng sắc — Tue, 07 Jul 2026 18:40:17 +0000

SARGable predicate: vì sao `DATE(created_at) = ...` giết index và bảng 50M row phải Seq Scan

Một predicate được gọi là SARGable (Search ARGument Able) khi planner có thể ánh xạ nó thẳng xuống cấu trúc index — cụ thể với B-Tree là ánh xạ vào key của leaf entry để đi tree hoặc scan range trên sibling. Khi cột bị bọc trong function hay bị ép kiểu (cast) ở vế trái của WHERE, giá trị mà planner cần so khớp không còn là giá trị lưu trong index nữa; nó phải tính function cho từng row, tức là Seq Scan. Đây là dạng "index có sẵn nhưng không dùng" gặp thường xuyên nhất trong production Postgres, và cũng là loại chậm khó nhìn nhất trong code review vì query "trông có filter". Việc sửa thường không phải thêm index — mà là viết lại predicate.

Cơ chế hoạt động

Postgres B-Tree lưu leaf entry theo giá trị nguyên bản của cột (đúng hơn: theo output của opclass đã dùng lúc CREATE INDEX). Planner nhìn WHERE clause, cố match từng predicate về dạng indexed_column OP constant để tạo Index Cond; dạng nào không match sẽ rớt xuống Filter sau khi row đã được đọc. Với WHERE created_at >= $1 AND created_at < $2, planner có thể đi thẳng vào leaf tại $1 rồi quét ngang tới $2. Với WHERE DATE(created_at) = $1, nó không có cách nào biết DATE(created_at) bằng gì nếu không đọc từng row và tính — vì index lưu timestamptz, không lưu date của nó.

-- Bảng events 50M row, có index (btree) trên created_at
CREATE INDEX events_created_at_idx ON events (created_at);

-- SARGable: predicate là range trên chính cột đã index
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM events
WHERE created_at >= '2026-06-01'
  AND created_at <  '2026-06-02';
-- Index Scan using events_created_at_idx  (rows=... loops=1)
--   Index Cond: ((created_at >= ...) AND (created_at < ...))

-- Non-SARGable: cột bị bọc bởi function
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM events
WHERE DATE(created_at) = '2026-06-01';
-- Seq Scan on events  (rows=... loops=1)
--   Filter: (date(created_at) = '2026-06-01'::date)
--   Rows Removed by Filter: 49_xxx_xxx

Hai điều kiện logic tương đương, plan khác nhau hoàn toàn. Postgres có hỗ trợ expression index (CREATE INDEX ON events (DATE(created_at))) để lưu chính giá trị của biểu thức và match lại được predicate — theo Postgres docs mục "Indexes on Expressions". Nhưng expression index chỉ khớp khi biểu thức trong WHERE và biểu thức trong CREATE INDEX giống hệt nhau về chuẩn hoá (cùng function, cùng cast, cùng collation). Đổi từ DATE(created_at) sang created_at::date vẫn có thể miss index nếu chưa index đúng biểu thức đó — planner không "hiểu ngữ nghĩa", nó match theo cây biểu thức đã được canonicalize.

Nguyên tắc rút ra: cột được index phải xuất hiện trần trụi ở vế trái của phép so sánh; mọi biến đổi phải đẩy sang vế phải (constant, hoặc tham số). Đó là định nghĩa thực dụng của SARGable trong Postgres.

Vấn đề gặp trong production

Failure mode 1: DATE()/date_trunc() bọc cột timestamp. Đây là mẫu phổ biến nhất từ code báo cáo và filter theo ngày.

-- Sai: bọc cột → không dùng được index trên created_at
SELECT count(*) FROM orders
WHERE DATE(created_at) = '2026-06-01';

-- Đúng: viết lại thành range half-open, giữ cột trần
SELECT count(*) FROM orders
WHERE created_at >= '2026-06-01'
  AND created_at <  '2026-06-02';

Cách viết range còn xử lý đúng cả timezone và tiết kiệm không dùng function per-row. Nếu thực sự cần query theo ngày và không sửa được app, tạo expression index: CREATE INDEX ON orders ((created_at AT TIME ZONE 'UTC')::date) — nhưng phải khớp hệt biểu thức trong WHERE.

Failure mode 2: LOWER(email) cho case-insensitive lookup. Rất hay xuất hiện ở table users với query login.

-- Sai: LOWER() ở vế trái → Seq Scan trên bảng users triệu row
SELECT id FROM users WHERE LOWER(email) = LOWER($1);

Hai lựa chọn:

-- Cách 1: expression index (giữ nguyên query app)
CREATE INDEX users_email_lower_idx ON users (LOWER(email));

-- Cách 2: đổi kiểu cột sang citext (case-insensitive text)
ALTER TABLE users ALTER COLUMN email TYPE citext;
CREATE INDEX users_email_idx ON users (email);
-- Query giữ nguyên WHERE email = $1, so sánh tự động case-insensitive

Chọn citext nếu app luôn muốn ngữ nghĩa case-insensitive; chọn expression index nếu chỉ vài query cần.

Failure mode 3: implicit cast ở vế trái. Cột kiểu bigint bị so sánh với text, hoặc ngược lại, khiến Postgres phải cast cột.

-- Sai: cast tường minh cột sang text để so string
SELECT * FROM orders WHERE user_id::text = '12345';

Postgres đôi khi cast constant sang kiểu cột (SARGable giữ nguyên), nhưng nếu vế trái có cast tường minh thì index không match. Bắt lỗi này thường phải nhìn EXPLAIN cho ra Filter: ((user_id)::text = '12345'::text) — dấu ngoặc quanh (user_id)::text là chỉ báo cột đã bị cast.

Failure mode 4: số học trên cột. WHERE price * 1.1 > 100 hay WHERE created_at + interval '30 days' < now() đều đẩy tính toán vào từng row.

-- Sai: cộng interval vào cột
SELECT * FROM subscriptions
WHERE created_at + interval '30 days' < now();

-- Đúng: chuyển sang vế phải
SELECT * FROM subscriptions
WHERE created_at < now() - interval '30 days';

Vế phải now() - interval '30 days' được đánh giá một lần thành constant tại thời điểm plan, index trên created_at dùng được ngay.

Failure mode 5: LIKE '%foo%' và leading wildcard. B-Tree phục vụ prefix LIKE 'foo%' (với opclass phù hợp) nhưng không phục vụ leading wildcard '%foo' hay '%foo%' — không có prefix để đi tree.

-- Sai: leading wildcard, index trên name không giúp
SELECT id FROM products WHERE name LIKE '%widget%';

-- Đúng cho substring/fuzzy: GIN + pg_trgm
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE INDEX products_name_trgm_idx ON products USING GIN (name gin_trgm_ops);
SELECT id FROM products WHERE name ILIKE '%widget%';

Failure mode 6: OR bắc cầu qua nhiều cột. WHERE user_id = $1 OR email = $2 khiến planner khó dùng chung một index; nó có thể chọn BitmapOr nếu có index trên cả hai cột, nhưng nếu chỉ có index trên user_id thì cả câu Seq Scan. Cách sửa gọn nhất: viết lại thành UNION ALL hai câu, mỗi câu là SARGable đơn lẻ.

Cách debug và monitor

Triệu chứng: một query "trông đơn giản" chậm bất thường khi bảng lớn dần; latency P99 tăng tuyến tính theo số row bảng chứ không theo số row trả về; CPU của Postgres cao mà buffer hit rate vẫn tốt (vì đang scan sequential mà data đã trong cache).

Công cụ để dò:

EXPLAIN (ANALYZE, BUFFERS) — dấu hiệu cần bắt: Seq Scan kèm Filter: (some_func(col) = ...), hoặc Rows Removed by Filter lớn hơn nhiều lần rows cuối. So predicate xuất hiện ở Index Cond: (tốt) hay Filter: (rơi ra sau khi đọc row) — predicate rơi vào Filter là dấu hiệu không SARGable.
pg_stat_user_indexes — cột idx_scan. Nếu một index được kỳ vọng dùng cho query nóng mà idx_scan gần bằng 0 sau khi workload đã chạy, khả năng cao query bên app đang viết non-SARGable. Đối chiếu với pg_stat_user_tables.seq_scan của bảng đó: seq_scan cao + idx_scan thấp trên cùng bảng là chỉ báo mạnh.
pg_stat_statements — sort theo total_exec_time hoặc mean_exec_time. Query top thường lộ ra DATE(), LOWER(), ::text bọc cột. Đây là input chính để refactor.
auto_explain — bật auto_explain.log_min_duration để log plan của query chậm vào Postgres log; giúp bắt câu ad-hoc mà pg_stat_statements chỉ giữ dạng normalized.

Rule phòng ngừa ở tầng code:

Code review bắt mọi WHERE clause có function/cast ở vế trái. Trong Python/Node ORM, cẩn thận helper kiểu Order.filter(created_at__date=today) — nó thường generate ra DATE(created_at) = .... Ưu tiên helper dạng __range hoặc __gte/__lt.
Với cột case-insensitive, quyết định một lần ở schema: citext hoặc expression index — đừng để nửa app dùng LOWER() nửa app dùng citext.
Với cột timestamptz, thống nhất chuẩn hoá về UTC ở app, filter luôn dạng range half-open [start, end).

Tradeoff

Hai hướng xử lý non-SARGable: viết lại SQL hoặc thêm expression index. Viết lại SQL rẻ hơn về mọi mặt (không tốn storage, không cost write, không cần deploy migration), nhưng đòi hỏi sửa code app hoặc ORM, và mọi call site phải đồng bộ. Expression index giữ nguyên query nhưng thêm một index thật vào bảng — mỗi INSERT/UPDATE trên cột base phải update index này; nếu expression phức tạp (function chậm, immutable-only), cost write tăng đáng kể. Ngoài ra expression index chỉ match khi biểu thức trong WHERE giống hệt biểu thức lúc CREATE INDEX (sau canonicalize) — dễ bị "index có mà không dùng" nếu app đổi cách viết. Với cột updated_at/created_at write-heavy, viết lại SQL luôn thắng expression index. Với legacy code không sửa được và một biểu thức ổn định (LOWER(email)), expression index là lựa chọn đúng. Quy tắc thực tế: mặc định đổi SQL cho SARGable; chỉ thêm expression index khi không thể sửa call site và biểu thức là stable + immutable.

Câu hỏi phỏng vấn

Query SELECT * FROM orders WHERE DATE(created_at) = '2026-06-01' chạy chậm dù đã có index btree(created_at). Vì sao, và có mấy cách sửa?

B-Tree lưu leaf entry theo giá trị timestamptz nguyên bản của created_at; planner match predicate về dạng col OP const để tạo Index Cond. Ở đây vế trái là DATE(created_at) — một biểu thức trên cột, không phải cột trần — nên không có Index Cond khớp được, planner rơi xuống Seq Scan với DATE(created_at) = ... nằm trong Filter, tức là đọc hết bảng rồi mới lọc. Đây là non-SARGable predicate: cột bị bọc function ở vế trái. Có hai cách sửa. Cách một, viết lại thành range half-open created_at >= '2026-06-01' AND created_at < '2026-06-02'; predicate lúc này SARGable, dùng Index Scan trên index sẵn có, cost giảm từ O(N) xuống O(log N + k). Cách hai, tạo expression index CREATE INDEX ON orders (DATE(created_at)); khi ấy leaf lưu chính giá trị date, predicate cũ match được — đổi lại phải trả cost write cho index mới và biểu thức trong WHERE phải khớp hệt biểu thức khi tạo index. Điểm ăn điểm là nêu được cả ba: cơ chế (index lưu giá trị cột nguyên bản, function ở vế trái phá match), hậu quả production (Seq Scan bảng lớn → P99 tăng theo size chứ không theo kết quả), và trade-off giữa viết lại SQL (rẻ, ưu tiên) và expression index (giữ nguyên app, đắt hơn write) — mặc định chọn cách một.

Hands-on

Mục tiêu: dựng một bảng đủ lớn, tái hiện non-SARGable → Seq Scan, đo EXPLAIN, refactor sang SARGable, so sánh, rồi thử luôn expression index để thấy trade-off.

docker run -d --name pg-sarg -e POSTGRES_PASSWORD=pw -p 5433:5432 postgres:16
sleep 5

docker exec -i pg-sarg psql -U postgres <<'SQL'
CREATE TABLE events (
  id          bigserial PRIMARY KEY,
  user_id     bigint      NOT NULL,
  email       text        NOT NULL,
  created_at  timestamptz NOT NULL
);

INSERT INTO events (user_id, email, created_at)
SELECT (random()*1000000)::bigint,
       'user' || (random()*1000000)::bigint || '@Example.COM',
       now() - (random() * interval '365 days')
FROM generate_series(1, 5000000);

CREATE INDEX events_created_at_idx ON events (created_at);
CREATE INDEX events_email_idx      ON events (email);
ANALYZE events;
SQL

Chạy phiên bản non-SARGable và ghi plan:

docker exec -i pg-sarg psql -U postgres -c "
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM events
WHERE DATE(created_at) = (now() - interval '10 days')::date;"

Kỳ vọng: Seq Scan on events, Filter: (date(created_at) = ...), Rows Removed by Filter gần bằng row count bảng, thời gian hàng trăm ms tới vài giây.

Refactor sang SARGable:

docker exec -i pg-sarg psql -U postgres -c "
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM events
WHERE created_at >= (now() - interval '10 days')::date
  AND created_at <  (now() - interval '9 days')::date;"

Kỳ vọng: Index Scan (hoặc Bitmap Index Scan) trên events_created_at_idx, Index Cond chứa hai vế range, thời gian sub-millisecond tới vài ms.

Thử case LOWER(email):

docker exec -i pg-sarg psql -U postgres -c "
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM events WHERE LOWER(email) = 'user42@example.com';"

Seq Scan như dự đoán. Thêm expression index và rerun:

docker exec -i pg-sarg psql -U postgres -c "
CREATE INDEX events_email_lower_idx ON events (LOWER(email));
ANALYZE events;
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM events WHERE LOWER(email) = 'user42@example.com';"

Plan chuyển sang Index Scan using events_email_lower_idx. Kiểm chứng cost write: đo TPS insert trước và sau khi có expression index:

cat > /tmp/insert.sql <<'EOF'
INSERT INTO events (user_id, email, created_at)
VALUES ((random()*1000000)::bigint,
        'user' || (random()*1000000)::bigint || '@Example.COM',
        now());
EOF
docker cp /tmp/insert.sql pg-sarg:/tmp/insert.sql

docker exec -i pg-sarg psql -U postgres -c "DROP INDEX events_email_lower_idx;"
docker exec pg-sarg pgbench -U postgres -n -f /tmp/insert.sql -c 8 -j 2 -T 20 postgres

docker exec -i pg-sarg psql -U postgres -c "CREATE INDEX events_email_lower_idx ON events (LOWER(email));"
docker exec pg-sarg pgbench -U postgres -n -f /tmp/insert.sql -c 8 -j 2 -T 20 postgres

TPS lần hai sẽ thấp hơn lần đầu — đây là chi phí thật của expression index, đối trọng để cân nhắc so với việc refactor query.

Kiểm tra index usage tổng thể:

docker exec -i pg-sarg psql -U postgres -c "
SELECT indexrelname, idx_scan, idx_tup_read
FROM pg_stat_user_indexes
WHERE schemaname = 'public'
ORDER BY idx_scan DESC;"

Index nào idx_scan = 0 dù có query kỳ vọng dùng nó → soi lại call site xem WHERE có bọc cột không. Dọn:

docker rm -f pg-sarg