Systems101

Right now we only have a singer user system, but for any real system, we must allow many users use the system. So we need: user register/login and each of them owns their wallets. It very similar with other application so I will skip. In this section we will discuss more about how backend sign the transaction.

The signature problem: proof of ownership

When Alice send ETH, the blockchain asks: “Is this really from Alice?”, Alice need to proof that she is owner of the wallet.

Non-Custodial vs Custodial: The Key Difference between our system with Metamask

For simplicity, we store users’ private keys in the database, but never in plain text. The keys are encrypted at rest and decrypted only when the backend needs to sign a transaction.

Unlike passwords, private keys cannot be hashed. Hashing is a one-way operation, which means the original key cannot be recovered. Since transaction signing requires access to the actual private key, encryption is necessary instead of hashing.

// Encryption with random IV per key
function encryptPrivateKey(key) {
  const iv = crypto.randomBytes(16);  // Random IV
  const cipher = crypto.createCipheriv(
    'aes-256-cbc',
    process.env.ENCRYPTION_KEY,  // 32 bytes
    iv
  );
  const encrypted = cipher.update(key, 'utf8', 'hex');
  return iv.toString('hex') + ':' + encrypted;
}

// Decryption
function decryptPrivateKey(encrypted) {
  const [ivHex, encryptedData] = encrypted.split(':');
  const iv = Buffer.from(ivHex, 'hex');
  const decipher = crypto.createDecipheriv(
    'aes-256-cbc',
    process.env.ENCRYPTION_KEY,
    iv
  );
  return decipher.update(encryptedData, 'hex', 'utf8');
}

// Database stores (still encrypted):
encrypted_private_key: "a1b2c3d4e5f6:x9y8z7w6v5u4t3s2r1q0p9o8n7m6l5k4..."

If database is hacked:
  Attacker gets encrypted key
  Without ENCRYPTION_KEY → useless
  Your funds are safe ✅

Summary

We are build a production Web3 payment system that is reliable (never loses data), secure (encrypted keys, hashed passwords, JWT auth), scalable (multi-user, multi-token), and professional (industry patterns used by top companies). In next session, we will setup some frontend code with React pages and deploy in Sepolia testnet and move all servers in cloud then everyone can access it from anywhere. Very excited!!!

Resource

ERC20 Token Standard — The complete spec
ethers.js Documentation — Blockchain interactions in JavaScript
The Graph — Learn advanced indexing patterns
AWS: Exponential Backoff — Retry strategies explained
JWT.io — Token-based authentication

How Ethereum Knows You Own Your Wallet Without Knowing Your Private Key

Quang — Wed, 03 Jun 2026 09:53:46 GMT

We're taking a short break from our wallet-building series to dive into an interesting cryptography concept. Have you ever wondered how Ethereum knows that you own a wallet, even though your private key never leaves your computer? In this article, we'll uncover the cryptographic magic that makes this possible.

But why we not just given the Ethereum the private key, like we are input password in a bank application?

This is one of the key differences between Web2 and Web3 applications.

In the Web2 world, there is usually a trusted organization in the middle, such as a bank. When you enter your password into a banking application, you trust the bank to store that password securely and not misuse it. You also trust that the bank will protect your account after you log out.

In the Web3 world, there is no central authority that everyone trusts. Instead, everything operates on a peer-to-peer network. Because there is no trusted intermediary, you should never reveal your private key to anyone—not even the network itself.

So we need a different approach.

We need a way to prove that you own a wallet without ever showing your private key. Anyone should be able to verify that you are the owner, but nobody should be able to use that proof to recover or steal your private key.

This is exactly the problem that modern cryptography solves.

Public key (asymmetric) cryptography

We discussed this topic in a previous post (you can read more there), but here’s a quick recap.

Asymmetric cryptography uses two related keys: a public key and a private key. The public key can be shared freely, while the private key must be kept secret.

There is an important mathematical relationship between the private key and the public key. Starting with a private key, generating the corresponding public key is easy. However, going in the opposite direction is extremely difficult. Even if everyone knows your public key, they cannot realistically calculate your private key. This property allows us to share public keys openly while keeping private keys secret.

In our previous post, we explored RSA, one of the most well-known public-key cryptography algorithms. In this article, we’ll focus on Elliptic Curve Cryptography (ECC), which is the cryptographic system used by Ethereum.

What is Elliptic Curve (EC)?

An elliptic curve is a special type of algebraic curve. Every point ((x, y)) on the curve satisfies the following equation.

This is some graphs of EC with some real numbers

Graphs of curves y² = x³ − x and y² = x³ − x + 1. Source: https://en.wikipedia.org/wiki/Elliptic_curve

In the EC, we define 2 operations: Addition and Multiplication.

Elliptic curve addition

Elliptic curve addition is defined such that given two points P1 and P2 on the elliptic curve, there is a third point P3 = P1 + P2, also on the elliptic curve.

Geometrically, this third point P3 is calculated by drawing a line between P1 and P2. This line will intersect the elliptic curve in exactly one additional place (amazingly). Call this point P3′ = (x, y). Then reflect in the x-axis to get P3 = (x, –y), as you can see in this images.

Elliptic curve addition: adding two points on an elliptic curve. Source https://masteringethereum.xyz/chapter_4.html

How about P1 and P2 are same points, there will infinite lines draw from only 1 point. In this case, we define addition as follow: draw a line "between" P1 and P2 and extend to be the tangent to the curve at this point P1. This tangent will intersect the curve at exactly one new point. Then we reflect this point in the x-axis and we found the point P3. Please see the image to more detail.

Elliptic curve addition: adding a point to itself. Source: https://masteringethereum.xyz/chapter_4.html

Point Multiplication

We are define a add operator than we can multiple multiplication, example with a non-negative integer number k, we define k * P = P + P + … + P (k times)

Public key generation

With the private key k we can generate public key K by

Where:

k is the private key, just a number, for example 123456.
K is the public key, represented by a pair of numbers (x, y).
G is the generator point. In Bitcoin and Ethereum, we use an elliptic curve called secp256k1. The shape of this curve is illustrated in the images above. The generator point G is a predefined constant that is the same for everyone. As a result, the same private key will always generate the same public key.

Please note:

The public key is derived from the private key by performing elliptic curve point multiplication:
K = k × G
Conceptually, this can be thought of as adding G to itself k times.
While it is easy to compute the public key from the private key, the reverse operation is considered computationally infeasible. Given a public key, there is currently no practical way to recover the corresponding private key. This one-way property is what makes elliptic curve cryptography secure.
The + operation here is not the normal addition we use in everyday arithmetic. It is a special point addition operation defined by the mathematical rules of elliptic curves, which we introduced in the previous section.

Ethereum Addresses

The Ethereum address is not the public key itself. Instead, it is derived by hashing the public key using Keccak-256 and taking the last 20 bytes of the result.

Some code to generate keys

Please note do not use random function in Python or Javascript to create private key, it is not real random numbers

A private key is just a 256-bit integer, and the public key is a point (x, y) on the secp256k1 elliptic curve generated by scalar multiplication.

# hex
k = f8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b2705608452f315 

# dex
k = 114169037863506835968652656006409564295731967028707949882771072938189669362709

We generate a public key:

const EC = require("elliptic").ec;

const ec = new EC("secp256k1");

const k = "f8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b2705608452f315";

const key = ec.keyFromPrivate(k);

const publicKey = key.getPublic();

console.log("x:", publicKey.getX().toString("hex"));
console.log("y:", publicKey.getY().toString("hex"));


// uncompressed public key (04 + x + y)
const pubKeyEncoded = publicKey.encode("hex", false);
console.log("publicKey (uncompressed):", pubKeyEncoded);

// remove 0x04 prefix
const pubKeyNoPrefix = pubKeyEncoded.slice(2);

// keccak256 hash of public key
const hash = keccak256("0x" + pubKeyNoPrefix);

// Ethereum address = last 20 bytes
const address = "0x" + hash.slice(-40);

console.log("address:", address);


// Output:

x: 6e145ccef1033dea239875dd00dfb4fee6e3348b84985c92f103444683bae07b
y: 83b5c38e5e2b0c8529d7fa3f64d46daa1ece2d9ac14cab9477d042c84c32ccd0
publicKey (uncompressed): 046e145ccef1033dea239875dd00dfb4fee6e3348b84985c92f103444683bae07b83b5c38e5e2b0c8529d7fa3f64d46daa1ece2d9ac14cab9477d042c84c32ccd0
address: 0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9

Summary

Thanks for reading this post — this topic can get quite complex when it comes to cryptography.

I’m trying to approach it from a software engineer’s perspective, rather than that of a cryptography expert. These concepts are important because they help us understand how the network actually works under the hood.

Public key cryptography has many applications beyond just generating public keys. For example, it is used to sign transactions, ensuring that only the owner of a private key can authorize them.

We will explore this in more detail in future posts.

Feel free to ask any questions in the comments.

Building a Web3 Wallet from Scratch: Phase 3 - Database & Event Indexing

Quang — Wed, 03 Jun 2026 03:57:02 GMT

Source code: https://github.com/quang-ng/Mini-Web3-Wallet-and-Payment/tree/b52fe9cbdb55a37d69492553f9d3097123fb8c96

Overview

Phase 3 marks a critical milestone in your Web3 wallet development journey. You've moved beyond basic smart contracts and APIs to implement a production-grade blockchain indexing system. This phase introduces PostgreSQL database integration, real-time event listening, and comprehensive transaction history tracking.

System Architecture

High-Level Data Flow

This is event-driven approach with this flow:

Smart Contract Emits Events - User performs deposit/withdraw, smart contract emits event with transaction data
Event Listener Catches Events - Background service running 24/7 listens for smart contract events in real-time
Extract Event Data - Listener extracts: user address, transaction amount, block number, and transaction type
Database Service Validates - Validates incoming data for integrity and correctness before storage
PostgreSQL Stores Data - Transaction data persisted permanently in database tables
REST API Provides Access - Users query transaction history anytime through REST endpoints
Frontend Displays Data - Client applications fetch and display transaction history to end users
Share

User Flow

Example user deposit 5 ETH

User clicks deposit - Frontend sends POST request with 5 ETH
Backend receives - Validates the amount and calls smart contract
Contract executes - Receives 5 ETH and updates its balance
Event emitted - Smart contract emits Deposit event with user data
Listener catches - Event Listener (always running) catches the event instantly
Database validates - Database Service validates and formats the data
Data stored - Transaction permanently saved to PostgreSQL
User queries - Later, user requests their transaction history
Instant response - REST API queries database and returns all transactions instantly

Implementation Details

Event Listener Implementation

The Event Listener runs continuously and watches for smart contract events:

// File: src/workers/eventListener.ts
// Import required modules
import { contract, provider } from '../config/contract';
import { insertTransaction } from '../db/transactionDb';

export async function startEventListener() {
  console.log('[EventListener] Starting blockchain event listeners...');

  // Listen for Deposit events from smart contract
  contract.on('Deposit', async (user, amount, event) => {
    console.log(`[Deposit Event] ${user} deposited ${amount} Wei`);

    try {
      await insertTransaction(
        user,
        amount.toString(),
        'deposit',
        `tx-${Date.now()}`,
        'confirmed',
        event.blockNumber
      );
      console.log('[EventListener] Transaction saved to database');
    } catch (error) {
      console.error('[EventListener] Error saving transaction:', error);
    }
  });

  // Listen for Withdraw events from smart contract
  contract.on('Withdraw', async (user, amount, event) => {
    console.log(`[Withdraw Event] ${user} withdrew ${amount} Wei`);

    try {
      await insertTransaction(
        user,
        amount.toString(),
        'withdraw',
        `tx-${Date.now()}`,
        'confirmed',
        event.blockNumber
      );
    } catch (error) {
      console.error('[EventListener] Error saving transaction:', error);
    }
  });

  console.log('[EventListener] Event listeners active!');
}

Database Service Implementation

The Database Service handles all database operations with connection pooling:

// File:  src/db/transactionDb.ts
import { Pool } from 'pg';

// Create connection pool to PostgreSQL
const pool = new Pool({
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  host: 'localhost',
  port: 5432,
  database: 'web3_wallet',
});

// Insert new transaction into database
export async function insertTransaction(
  address: string,
  amount: string,
  type: 'deposit' | 'withdraw',
  txHash: string,
  status: string,
  blockNumber: number
) {
  const query = `
    INSERT INTO transactions
    (from_address, amount, type, tx_hash, status, block_number, created_at)
    VALUES ($1, $2, $3, $4, $5, $6, NOW())
    RETURNING *;
  `;

  const result = await pool.query(query, [
    address, amount, type, txHash, status, blockNumber,
  ]);
  return result.rows[0];
}

// Get all transactions for a specific address
export async function getTransactionsByAddress(address: string) {
  const query = `
    SELECT * FROM transactions
    WHERE from_address = $1
    ORDER BY created_at DESC;
  `;

  const result = await pool.query(query, [address]);
  return result.rows;
}

// Get all transactions in the system
export async function getAllTransactions() {
  const query = `
    SELECT * FROM transactions
    ORDER BY created_at DESC;
  `;

  const result = await pool.query(query);
  return result.rows;
}

API Routes Implementation

REST endpoints that allow clients to query transaction history:

// File: src/workers/eventListener.ts
import express from 'express';
import {
  getTransactionsByAddress,
  getAllTransactions
} from '../db/transactionDb';

const router = express.Router();

// GET /api/transaction/history/:address
// Returns all transactions for a specific wallet address
router.get('/history/:address', async (req, res) => {
  try {
    const { address } = req.params;

    // Validate Ethereum address format
    if (!address.startsWith('0x') || address.length !== 42) {
      return res.status(400).json({
        error: 'Invalid Ethereum address'
      });
    }

    // Query database for transactions
    const transactions = await getTransactionsByAddress(address);

    return res.json({
      address,
      count: transactions.length,
      transactions,
    });
  } catch (error) {
    console.error('Error fetching transactions:', error);
    res.status(500).json({ error: 'Failed to fetch transactions' });
  }
});

// GET /api/transaction/all
// Returns all transactions in the system
router.get('/all', async (req, res) => {
  try {
    const transactions = await getAllTransactions();

    res.json({
      total: transactions.length,
      transactions,
    });
  } catch (error) {
    console.error('Error fetching all transactions:', error);
    res.status(500).json({ error: 'Failed to fetch transactions' });
  }
});

export default router;

Server Integration

How everything connects in your main server file:

// File: src/index.ts
import express from 'express';
import { startEventListener } from './workers/eventListener';
import transactionRoutes from './routes/transaction';

const app = express();
const PORT = 3000;

// Middleware for parsing JSON requests
app.use(express.json());

// Register all transaction API routes
app.use('/api/transaction', transactionRoutes);

// Start server and event listener
app.listen(PORT, async () => {
  console.log(`✅ Server running on http://localhost:${PORT}`);

  // Start event listener in background (24/7)
  await startEventListener();
});

Testing with CLI - Send Requests & Get Responses

Start the service

# Start the backend server
npm run dev

# Expected output:
✅ Server running on http://localhost:3000
[EventListener] Event listeners active!

Make a Deposit Transaction

Use deposit 2ETH into the smart contract

# Make a POST request to deposit 2 ETH
curl -X POST http://localhost:3000/api/transaction/deposit \
  -H "Content-Type: application/json" \
  -d '{"amount": "2"}'

# Reponse:
{
  "success": true,
  "message": "Deposit transaction sent",
  "transactionHash": "0x7a2c4f...",
  "amount": "2",
  "amountInWei": "2000000000000000000"
}

Logic:

Your deposit is sent to the smart contract
Smart contract emits Deposit event
Event Listener catches it instantly
Transaction saved to PostgreSQL database
Data is now queryable via REST API

Make a Withdraw Transaction

User want to withdraw 0.5ETH

# Make a POST request to withdraw 0.5 ETH
curl -X POST http://localhost:3000/api/transaction/withdraw \
  -H "Content-Type: application/json" \
  -d '{"amount": "0.5"}'
## Reposne: 
{
  "success": true,
  "message": "Withdrawal transaction sent",
  "transactionHash": "0x8b3d5e...",
  "amount": "0.5",
  "amountInWei": "500000000000000000"
}

Query Transaction History for a User

Retrieve all past transactions for a specific wallet address:

# Query transaction history for wallet address
curl http://localhost:3000/api/transaction/history/0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266

## Response:
{
  “address”: “0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266”,
  “count”: 3,
  “transactions”: [
    {
      “id”: 3,
      “tx_hash”: “pending-1779774582045”,
      “from_address”: “0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266”,
      “amount”: “500000000000000000”,
      “type”: “withdraw”,
      “status”: “confirmed”,
      “block_number”: 15,
      “created_at”: “2026-05-26T14:32:25.045Z”
    },
    {
      “id”: 2,
      “tx_hash”: “pending-1779774580719”,
      “from_address”: “0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266”,
      “amount”: “2000000000000000000”,
      “type”: “deposit”,
      “status”: “confirmed”,
      “block_number”: 13,
      “created_at”: “2026-05-26T14:30:20.719Z”
    },
    {
      “id”: 1,
      “tx_hash”: “pending-1779774578500”,
      “from_address”: “0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266”,
      “amount”: “5000000000000000000”,
      “type”: “deposit”,
      “status”: “confirmed”,
      “block_number”: 11,
      “created_at”: “2026-05-26T14:29:38.500Z”
    }
  ]
}

Summary

In this section, we build:

PostgreSQL database with 2 tables
24/7 event listener service
2 REST API endpoints
Real-time blockchain indexing

What we’ve got:

Capture events in real-time
Store data persistently
Query history instantly
Foundation for production systems

Next: Phase 4 - Enhancement

Phase 4 will add security, validation, and production features:

Request validation and user authentication
Rate limiting and security hardening
Initial blockchain sync on startup
Transaction retry logic and better error handling
Pagination for large datasets
ERC20 token support
Leave a comment

Building a Web3 Wallet from Scratch: Phase 2 — Backend as the Bridge

Quang — Tue, 02 Jun 2026 10:18:15 GMT

Source code: https://github.com/quang-ng/Mini-Web3-Wallet-and-Payment/tree/c5f0f82358fb1af2f4ad425e3523dd7326dce24b

The Shift: From Smart Contracts to Services

Phase 1 was about building the foundation—a rock-solid smart contract that lives immutably on-chain. Phase 2 is about building the layer on top.

The reality: smart contracts can't talk to users directly. They live on the blockchain. Users live in browsers and apps. The backend is the bridge—a REST API that users call, which calls the blockchain on their behalf.

This phase taught me that backend development in Web3 is different. You're not managing a database—you're managing transactions. You're not authenticating users—you're signing transactions. You're not storing data—you're reading it from an immutable ledger.

Architecture: The Three-Layer Stack

Before I started, I thought the backend would be simple—just pass requests through to the blockchain. I was wrong. The backend does the thinking. The contract just holds the state.

What I Actually Built

Starting point: zero configuration. Here's the entry file that boots everything:

// src/index.ts
import express, { Request, Response } from "express";
import { config } from "./config";
import walletRouter from "./routes/wallet";
import transactionRouter from "./routes/transaction";

const app = express();
app.use(express.json());

// Routes
app.use("/api/wallet", walletRouter);
app.use("/api/transaction", transactionRouter);

app.listen(config.PORT, () => {
  console.log(`Server running on http://localhost:${config.PORT}`);
});

Express parses incoming JSON requests
Two route groups: /api/wallet/ and api/transaction
Server boots on port 3000

Connecting to the Blockchain: ethers.js Setup

// src/blockchain/provider.ts
import { JsonRpcProvider, Wallet } from "ethers";
import { config } from "../config";

// Connect to the blockchain (Anvil local node)
const provider = new JsonRpcProvider(config.RPC_URL);

// Create a signer—a wallet that can sign transactions
const signer = new Wallet(config.PRIVATE_KEY, provider);

export { provider, signer };

- JsonRpcProvider: Connects to the blockchain via HTTP. Every call goes to the RPC endpoint (Anvil, Infura, Alchemy, etc.)
- Wallet: Holds a private key and can sign transactions. This wallet pays gas and sends transactions on behalf of the backend.
Mental model: The backend is like a trusted friend who holds your credit card. When you (frontend) say "deposit," the backend signs the transaction with its key.

// src/blockchain/contract.ts
import { Contract } from "ethers";
import { signer } from "./provider";
import { config } from "../config";
import ABI from "./abi";

const contract = new Contract(
  config.CONTRACT_ADDRESS,
  ABI,
  signer
);

export { contract };

The contract instance is the gateway. It knows:
- The contract's address on-chain
- The contract's interface (ABI—what functions exist)
- The signer that will call those functions

The Business Logic: Services

// src/services/walletService.ts
import { provider, signer } from "../blockchain/provider";

export class WalletService {
  async getBalance(address: string): Promise {
    // Read-only call to contract
    const balance = await provider.getBalance(address);
    return balance.toString();
  }

  async getSignerAddress(): Promise {
    // What address is this backend running as?
    return await signer.getAddress();
  }

  async getNetworkInfo() {
    // Useful for debugging and validation
    const network = await provider.getNetwork();
    return {
      name: network.name,
      chainId: network.chainId,
      rpcUrl: provider.connection.url,
    };
  }
}

Key distinction: These methods are pure blockchain reads. No transaction signing. No gas costs. Just querying state.

// src/services/transactionService.ts
import { parseEther, formatEther } from "ethers";
import { contract } from "../blockchain/contract";

export class TransactionService {
  async deposit(amountEth: string) {
    // Convert user input (ETH) to Wei (contract units)
    const amountWei = parseEther(amountEth);

    // Send a transaction to the contract
    const tx = await contract.deposit({ value: amountWei });

    // Wait for blockchain confirmation (1 block by default)
    const receipt = await tx.wait();

    return {
      hash: tx.hash,
      blockNumber: receipt?.blockNumber,
      status: receipt?.status === 1 ? "success" : "failed",
    };
  }

  async withdraw(amountEth: string) {
    const amountWei = parseEther(amountEth);
    const tx = await contract.withdraw(amountWei);
    const receipt = await tx.wait();

    return {
      hash: tx.hash,
      blockNumber: receipt?.blockNumber,
      status: receipt?.status === 1 ? "success" : "failed",
    };
  }
}

What’s really happening:

parseEther() converts human-readable “1.5 ETH” to “1500000000000000000 Wei”
contract.deposit() signs and sends a transaction to the blockchain
.wait() blocks until the transaction is mined (included in a block)
Response includes the transaction hash (proof it happened)

Key Concepts That Clicked

Wei vs. ETH: The Unit Problem

ETH is a human-readable unit. The blockchain operates in Wei—the smallest unit of ETH:

1 ETH = 1,000,000,000,000,000,000 Wei (10^18)
All contract operations use Wei
All smart contracts return numbers in Wei

First time I forgot this conversion, the backend crashed when the user entered “0.5 ETH”. The contract expected an integer and got a float. Always convert at the API boundary.

2. Transactions vs. Calls: State-Changing vs. Reading

The confusion: both are asynchronous, but transactions are slowly asynchronous. A call returns instantly. A transaction returns a promise that waits for blockchain confirmation.

What's Next: Phase 3?

Phase 2 proved the backend works. Phase 3 adds persistence:

PostgreSQL Database: Store transaction history (blockchain is append-only, but querying is expensive)

Event Listener: Watch contract events and sync to database
Indexer Worker: Background process that listens for Deposit/Withdraw events
Transaction History API: GET /api/transactions returns past deposits/withdrawals from the database
This transforms the backend from a transaction relay to a state indexer. Right now, if you want transaction history, you’d query Etherscan. Phase 3 makes you independent.

Building a Web3 Wallet from Scratch: Phase 1 — Smart Contracts & Testing

Quang — Tue, 02 Jun 2026 04:15:34 GMT

Source code: https://github.com/quang-ng/Mini-Web3-Wallet-and-Payment/tree/510ee4a62adf87cd392f28d89385402911fb09ec

The Journey

I decided to build a Web3 wallet application from scratch—not following tutorials, but truly understanding every line I write. Phase 1 focuses on the foundation: a rock-solid smart contract, comprehensive tests, and real-world deployment. This post walks you through the decisions, code, and lessons learned.

What I Actually Built

Thanks for reading Systems101! This post is public so feel free to share it.

The Smart Contract: PaymentVault.sol

At just 30 lines, this contract embodies blockchain fundamentals. Here’s the complete contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract PaymentVault {
    mapping(address => uint256) public balances;

    event Deposit(address indexed user, uint256 amount);
    event Withdrawal(address indexed user, uint256 amount);

    function deposit() external payable {
        require(msg.value > 0, "Deposit amount must be greater than 0");
        balances[msg.sender] += msg.value;
        emit Deposit(msg.sender, msg.value);
    }

    function withdraw(uint256 amount) external {
        require(amount > 0, "Withdraw amount must be greater than 0");
        require(balances[msg.sender] >= amount, "Insufficient balance");
        
        balances[msg.sender] -= amount;
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
        
        emit Withdrawal(msg.sender, amount);
    }

    function getBalance(address user) external view returns (uint256) {
        return balances[user];
    }
}

What this contract done:

Mapping for Balance Tracking: mapping(address => uint256) public balances; stores each user’s balance. Instead of an array (which would require iteration), mappings provide O(1) lookups—crucial for gas efficiency.
The Deposit Function: When a user calls deposit() and sends ETH:
- msg.value tells us how much ETH arrived (in Wei)
- msg.sender tells us who sent it
- We add to their balance and emit an event
- Example: User sends 1 ETH (1e18 Wei), their balance increases by 1e18
The Withdrawal Function: The critical part—we use a three-step checks-effects-interactions pattern:
- Check: Verify they have enough balance
- Effect: Reduce their balance
- Interact: Send the ETH using the safe call method
- This prevents reentrancy attacks
Events for Indexing: Every deposit/withdrawal emits an event. Frontends and indexers listen to these to track history without querying storage.

The Test Suite: PaymentVault.t.sol

Testing smart contracts is non-negotiable—bugs cost money. Here’s how I structured the tests:

Deployment & Real-World Testing

Step 1: Start a Local Blockchain with Anvil

anvil

This spins up a local Ethereum node on http://127.0.0.1:8545 with 10 pre-funded test accounts.

Step 2: Deploy via Script

// Deploy.s.sol
pragma solidity ^0.8.0;

import "forge-std/Script.sol";
import "../src/PaymentVault.sol";

contract DeployScript is Script {
    function run() external {
        vm.startBroadcast();
        PaymentVault vault = new PaymentVault();
        console.log("Deployed at:", address(vault));
        vm.stopBroadcast();
    }
}

then run this cmd

forge script script/Deploy.s.sol --rpc-url http://127.0.0.1:8545 --broadcast

Step 3: Interact with Cast

# Send a deposit (1 ETH)
cast send 0x5FbDB2315678afecb367f032d93F642f64180aa3 \
  "deposit()" \
  --value 1ether \
  --rpc-url http://127.0.0.1:8545 \
  --private-key 

# Check balance (no gas cost, read-only)
cast call 0x5FbDB2315678afecb367f032d93F642f64180aa3 \
  "getBalance(address)" \
  0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 \
  --rpc-url http://127.0.0.1:8545

# View transaction receipt & events
cast receipt  --rpc-url http://127.0.0.1:8545

Key Technical Concepts That Clicked

1. msg.sender & msg.value: The Transaction Context

Every blockchain transaction carries metadata about who initiated it and what they sent. In Solidity, these are global variables:

msg.sender: The caller’s address
msg.value: The amount of ETH sent (in Wei, where 1 ETH = 1e18 Wei)

2. Mappings Over Arrays: Gas Efficiency

Mappings use hash tables—instant access. On Ethereum, writing to storage costs ~20,000 gas. Iteration multiplies that cost. With a mapping, you pay the same whether you have 10 users or 10,000.

3. require() as a State Guardian

The require() statement isn’t just error handling—it’s a contract’s way of enforcing invariants:

4. Events: Blockchain’s Audit Trail

Smart contracts can’t directly send data to the frontend. Events solve this elegantly:

Event Deposit(address indexed user, uint256 amount);

function deposit() external payable {
    balances[msg.sender] += msg.value;
    emit Deposit(msg.sender, msg.value);
    // This event is permanently recorded on-chain
}

Frontend listening: Frontends subscribe to the Deposit event and update UI in real-time
Indexers: Services like The Graph listen to events and build queryable databases
Gas efficiency: Events are cheaper to store than contract storage (1,000 gas vs 20,000 gas)
Immutable history: Every deposit is forever recorded and can’t be altered

5. Test Coverage Philosophy: More Tests Than Code

I wrote 112 lines of tests for 30 lines of contract code—a 3.7x ratio.

What’s Next: Phase 2

The contract is solid and tested. Phase 2 builds the backend layer:

Express.js API: REST endpoints for deposits/withdrawals (no Web3 required)
ethers.js Integration: Connect to contract from Node.js
Transaction Management: Private key handling, nonce tracking, gas estimation
Database: User accounts, transaction history, metadata
Rate Limiting: Prevent abuse
RPC Provider: Reliable Ethereum endpoint (Infura/Alchemy)

The contract handles funds. The backend handles everything else.

Resources That Actually Helped

Foundry Docs (https://book.getfoundry.sh/): The vm.* helpers are incredibly powerful
Solidity Docs (https://docs.soliditylang.org/): Type system and modifiers explained clearly

Mastering Ethereum (https://github.com/ethereumbook/ethereumbook): Chapters 1-7 covered architecture
ethers.js Docs (https://docs.ethers.org/v6/): Everything needed for backend integration
Ethereum Yellow Paper (https://ethereum.org/en/developers/docs/): For deep understanding of gas costs and transaction mechanics

The Takeaway

Phase 1 taught me that blockchain development is about constraints, not complexity.

Thirty lines of contract code forced me to think clearly about state management and gas efficiency. Eleven tests forced me to think about edge cases and immutability implications. No hand-waving, no “we’ll fix it in prod”—every line matters.

The smart contract is the foundation. Everything else builds on top of it. Phase 2 connects it to users. Phase 3 gives them a UI.

Understanding Merkle Trees

Quang — Thu, 21 May 2026 03:01:57 GMT

When I first heard about Merkle Trees, I assumed they were some ultra-cryptic blockchain invention that only mattered in crypto. Turns out, the idea is actually pretty straightforward.

Imagine you’re building a distributed system and you have two servers storing the same dataset. Maybe they’re replicas in different regions. At some point you need to answer a simple question:

“Do these two machines still have the exact same data?”

If the dataset is small, easy — just compare everything.

But what if the dataset is several terabytes?

You obviously don’t want node A to send the entire dataset to node B every few minutes just to check consistency. That would destroy your network and probably your infrastructure budget too.

This is the kind of problem Merkle Trees solve really well.

The basic trick is surprisingly elegant. Instead of comparing raw data directly, you compare hashes.

Let’s say you have four pieces of data:

users_1
users_2
users_3
users_4

You hash each one individually:

H1 = hash(users_1)
H2 = hash(users_2)
H3 = hash(users_3)
H4 = hash(users_4)

Then you combine hashes together and hash them again:

H12 = hash(H1 + H2)
H34 = hash(H3 + H4)

And finally:

ROOT = hash(H12 + H34)

Now you have a single hash — the root hash — that represents the entire dataset underneath it.

What’s nice is that hashes are extremely sensitive to changes. If even one byte changes inside users_3, then H3 changes completely. Which means H34 changes. Which means the root changes too.

So now two servers can compare a single tiny value:

ROOT_A == ROOT_B

If they’re equal, the datasets are almost certainly identical. If not, you don’t immediately resend everything. You walk down the tree.

Maybe H12 matches but H34 doesn’t. Great — now you’ve narrowed the problem to half the dataset. Then you compare the next layer until eventually you identify exactly which chunk differs.

This diagram shows how a Merkle Tree turns many pieces of data into a single hash called the Merkle Root. Each transaction is hashed individually, then hashes are combined and hashed again upward through the tree. The interesting part is verification: instead of downloading the entire dataset, you only need a small set of sibling hashes to prove that a transaction belongs to the tree. This is why Merkle Trees are widely used in systems like Bitcoin, Git, and Apache Cassandra for efficient integrity checking and distributed synchronization.

That’s the part I think is really beautiful about Merkle Trees. They’re basically an efficient divide-and-conquer strategy for data verification.

Distributed databases like use Merkle Trees during repair operations between replicas. Torrent systems use similar ideas to verify file chunks. Even works with a very hash-oriented model where integrity flows upward through references.

Blockchain just happens to be the most famous example because systems like store thousands of transactions inside blocks and need efficient proofs that a transaction belongs to a block without downloading everything. But underneath all the hype, the actual idea is very backend-engineering-ish. You’re taking a large verification problem and reducing it into smaller hashes that are cheap to compare and easy to synchronize across machines.

Karpathy’s LLM Wiki là gì? Làm thế nào để xây dựng một "Personal Knowledge Base" với Claude Code

Quang — Thu, 09 Apr 2026 06:55:30 GMT

Karpathy’s LLM Wiki là gì

Ý tưởng cốt lõi rất đơn giản:
Những ghi chú cá nhân — chỉ cần viết dưới dạng Markdown có cấu trúc rõ ràng — không cần phụ thuộc vào Notion hay Google Docs, hoàn toàn có thể trở thành một knowledge base mà LLM có thể đọc, hiểu và khai thác.

Bài viết này sẽ giải thích:

LLM Wiki hoạt động như thế nào
Vì sao Markdown là lựa chọn phù hợp
Và cách bạn có thể bắt đầu với Obsidian chỉ trong 5 phút
Thanks for reading! Subscribe for free to receive new posts and support my work.

Sự khác biệt giữa note app thông thường và markdown text

Các ứng dụng ghi chú truyền thống chủ yếu phục vụ con người: bạn phải tự nhớ thông tin nằm ở đâu, rồi lần mò tìm lại bằng cách duyệt thư mục hoặc search thủ công.

Với LLM Wiki thì khác. Bạn chỉ cần mô tả điều mình cần bằng ngôn ngữ tự nhiên, LLM (ví dụ Claude) sẽ tìm kiếm và tổng hợp trên toàn bộ knowledge base. Model không quan tâm bạn tổ chức folder ra sao — nó chỉ “đọc” text.

Vì vậy, Markdown trở thành lựa chọn gần như lý tưởng:

Chỉ là text thuần với vài syntax đơn giản
Không bị lock-in, không cần export hay encoding phức tạp
Dễ đọc cho con người, cũng dễ hiểu với LLM

Nói ngắn gọn: Markdown là điểm giao nhau hoàn hảo giữa human-readable và LLM-friendly.

Cách Karpathy’s LLM Wiki hoạt động

Một folder chứa các markdown files: Folder này sẽ là knowledge base của bạn, nó sẽ chứa tất cả: research note, meeting summary, book notes..
Một cấu trúc thống nhất cho mỗi file: LLM wiki sẽ chỉ cần sử dụng consistent internal format ví dụ như title, sub title, topic and content.
Claude code dùng để query. Bạn mở terminal, di chuyển tới wiki folder, chạy Claude code sau đó bắt đầu hỏi. Claude code sẽ đọc files nào cần, sau đó trả lời, và có thể update các notes nếu cần.

Chỉ có thể, không càn database, vector embedding, server …

Vài trò của Claude Code

Claude Code là một coding agent chạy trong terminal của Anthropic. Khác với Claude trên trình duyệt, Claude Code chạy trực tiếp trên môi trường local của bạn và có quyền truy cập vào filesystem. Nó có thể:

Đọc từng file cụ thể hoặc cả thư mục
Tìm kiếm nội dung liên quan trên nhiều file
Tạo file mới hoặc cập nhật file hiện có
Thực thi các lệnh shell để tìm kiếm, lọc hoặc tổ chức lại ghi chú

Điều này khiến nó thực sự hữu ích như một interface cho knowledge base. Bạn không còn phải copy-paste từng đoạn text vào cửa sổ chat — model có thể làm việc trực tiếp với chính các file của bạn.

Một số thói quen cần cho một Knowledge base

Viết tóm tắt, không chỉ viết nội dung

Dòng tóm tắt một câu ở đầu mỗi ghi chú quan trọng hơn bạn nghĩ. Claude dùng nó để quyết định liệu có nên đọc toàn bộ nội dung hay không. Một summary tốt chỉ tốn 10 giây, nhưng giúp model tránh đọc những file không liên quan.

Sử dụng thuật ngữ nhất quán

Nếu bạn viết “RAG” ở chỗ này và “retrieval augmented generation” ở chỗ khác, Claude vẫn có thể hiểu — nhưng kết quả sẽ sạch và chính xác hơn nếu bạn chọn một thuật ngữ và dùng nhất quán. Nếu một khái niệm có nhiều tên, hãy thêm một dòng alias ngắn.

Liên kết các ghi chú với nhau

Format [[wiki links]] của Obsidian giúp tạo kết nối giữa các ghi chú. Claude có thể đi theo các liên kết này, nghĩa là một wiki được liên kết tốt sẽ cung cấp cho model một “graph tri thức” phong phú hơn so với một tập file rời rạc.

Giữ mỗi ghi chú tập trung

Một tài liệu 10,000 từ ôm nhiều chủ đề sẽ khó truy vấn hơn 10 ghi chú riêng biệt, mỗi cái 1,000 từ. Nếu một note đang bao phủ nhiều ý khác nhau, hãy tách ra. File càng cụ thể, Claude càng dễ tìm và sử dụng chính xác.

Dùng pattern /inbox để capture

Đừng để sự hoàn hảo cản trở tính hữu dụng. Hãy dump các ghi chú thô vào /inbox, sau đó định kỳ nhờ Claude giúp bạn dọn dẹp và sắp xếp lại:

“Hãy xem folder inbox của tôi và gợi ý mỗi ghi chú nên được lưu ở đâu và gắn tag gì.”

Kết luận

LLM Wiki theo kiểu Karpathy thực chất là một pattern rất đơn giản: dùng các file Markdown có cấu trúc làm knowledge base, và truy vấn chúng bằng ngôn ngữ tự nhiên thông qua Claude Code.

Markdown là lựa chọn phù hợp vì nó portable, không bị lock-in, bền vững theo thời gian, và LLM có thể đọc trực tiếp như text thuần. Để quản lý các file này, Obsidian là một front-end rất hiệu quả — dữ liệu vẫn nằm local, dưới dạng file, không phụ thuộc nền tảng.

Claude Code đóng vai trò cầu nối: nó truy cập trực tiếp vào filesystem của bạn, nên không cần copy-paste nội dung vào chat. Chỉ cần một dòng tóm tắt rõ ràng và hệ thống tag nhất quán cho mỗi note, chất lượng truy vấn sẽ cải thiện đáng kể.

Nếu cần mở rộng cho team hoặc chia sẻ rộng hơn, các công cụ như MindStudio có thể đóng gói cùng ý tưởng này thành một agent có UI hoàn chỉnh, không cần code.

Cuối cùng, hệ thống quản lý tri thức tốt nhất là hệ thống bạn thực sự dùng. Một folder Markdown là mức friction thấp nhất có thể — và để Claude “hiểu” được nó cũng chỉ mất vài phút. Hãy bắt đầu nhỏ, giữ mỗi note rõ ràng, và để hệ thống phát triển dần theo nhu cầu của bạn

Tham khảo

https://www.mindstudio.ai/blog/andrej-karpathy-llm-wiki-knowledge-base-claude-code
Leave a comment

Hiểu đúng về LLM: Retrieval-Augmented Generation (p2)

Quang — Thu, 26 Mar 2026 03:41:35 GMT

Phần này tập trung vào các hệ thống kết nối LLM với các nguồn tri thức bên ngoài (external knowledge sources), giúp câu trả lời của chúng được “neo” vào các tài liệu thực tế, cơ sở dữ liệu và những nguồn dữ liệu khác. Nội dung bao gồm toàn bộ pipeline RAG, từ chiến lược truy xuất, xử lý tài liệu, gán nguồn (attribution), cho đến việc mở rộng hệ thống (scaling) và debug. Những phần này giúp bạn hiểu RAG như là một hệ thống hoàn chỉnh chứ không chỉ dừng lại ở việc định nghĩa khái niệm

Thanks for reading! This post is public so feel free to share it.

RAG là gì và cách pipeline hoạt động như thế nào?

Retrieval-Augmented Generation (RAG) là một kiến trúc kết hợp giữa mô hình ngôn ngữ lớn (LLM) và hệ thống truy xuất thông tin nhằm tạo ra câu trả lời chính xác và có căn cứ hơn. Thay vì chỉ dựa vào kiến thức đã được huấn luyện sẵn (dễ bị lỗi thời hoặc “hallucination”), RAG sẽ truy vấn thêm dữ liệu từ các nguồn bên ngoài như tài liệu, database hoặc vector store.

Pipeline đầy đủ của RAG thường bắt đầu từ việc preprocessing (chia nhỏ tài liệu, embedding và lưu vào vector database), sau đó khi có truy vấn từ người dùng, hệ thống sẽ embedding query và thực hiện retrieval để tìm ra các đoạn văn liên quan nhất.

Những context này sẽ được đưa vào prompt của LLM trong bước augmentation, giúp mô hình sinh ra câu trả lời dựa trên thông tin đã truy xuất. Cuối cùng, hệ thống có thể bổ sung bước attribution (trích dẫn nguồn), cũng như các cơ chế ranking, filtering hoặc guardrails để cải thiện độ chính xác.

Toàn bộ pipeline này biến RAG thành một hệ thống end-to-end, nơi chất lượng không chỉ phụ thuộc vào LLM mà còn vào cách dữ liệu được xử lý, truy xuất và kiểm soát.

Những retrieval strategy thường được sử dụng và khi nào lên sử dụng strategy nào?

Trong các hệ thống RAG, việc lựa chọn retrieval strategy phù hợp quyết định trực tiếp đến chất lượng context đưa vào LLM. Có nhiều cách tiếp cận khác nhau, mỗi cách phù hợp với một loại bài toán cụ thể.

Dense retrieval (semantic search)

Dense retrieval sử dụng embedding và vector similarity để tìm các đoạn văn có ý nghĩa gần nhất với query. Cách này rất mạnh khi câu hỏi mang tính ngữ nghĩa, không cần trùng keyword chính xác. Ví dụ: người dùng hỏi “làm sao tối ưu pipeline dữ liệu lớn” thì vẫn có thể match với tài liệu nói về “scalable data processing system”.

Hình trên mô tả cách hệ thống thực hiện retrieval trong RAG bằng semantic search. Cả User Query và Document đều được đưa qua một pre-trained transformer (như BERT) để chuyển thành embedding — các vector số đại diện cho ý nghĩa của văn bản. Sau đó, hệ thống dùng cosine similarity để đo độ giống nhau giữa hai vector và chọn ra những tài liệu liên quan nhất.

Hạn chế:

Không tốt với exact keyword (VD: mã lỗi, tên sản phẩm)
Phụ thuộc mạnh vào chất lượng embedding model
Không hiểu context dài (nếu chunking kém)

Sparse Retrieval (Keyword-based)

Sparse retrieval dựa trên keyword matching và inverted index. Nó không hiểu ngữ nghĩa sâu nhưng rất chính xác khi query chứa từ khóa cụ thể.

Rất tốt khi:

Tìm kiếm log, error code, tên sản phẩm
Query có keyword rõ ràng
Cần exact match

Hybrid Retrieval

Hybrid retrieval kết hợp cả dense và sparse để tận dụng ưu điểm của cả hai: vừa hiểu ngữ nghĩa vừa không bỏ sót keyword quan trọng. Sau đó áp dụng reranking để sắp xếp lại kết quả, chỉ chọn những kết quả quan trọng nhất.

Làm sao để xử lý những documents là file PDF hàng trăm, hàng ngàn trang?

Khi xử lý các file PDF rất lớn, điểm quan trọng không nằm ở việc đưa toàn bộ nội dung vào LLM, mà là cách chuẩn bị dữ liệu để retrieval hoạt động hiệu quả.

Ở phase ingestion, sau khi extract và clean dữ liệu, cần đặc biệt chú ý đến cách xử lý các loại dữ liệu khác nhau. Với bảng biểu (tables), nên chuyển sang dạng structured (JSON hoặc markdown) để giữ được quan hệ giữa các hàng và cột, thậm chí có thể lưu riêng và kết hợp hybrid retrieval cho các truy vấn mang tính số liệu. Với hình ảnh (images), nếu chứa text thì dùng OCR, còn với biểu đồ hoặc sơ đồ thì nên tạo caption hoặc embedding bằng multimodal model để không mất thông tin quan trọng.

Ở phase retrieval, ngoài semantic search, thường cần thêm reranking hoặc kết hợp nhiều chiến lược để đảm bảo lấy đúng context trước khi đưa vào LLM.

Một điểm đáng chú ý là chất lượng hệ thống không chỉ phụ thuộc vào model, mà phần lớn nằm ở cách thiết kế pipeline — đặc biệt là chunking, cách xử lý tables và images, metadata, và retrieval strategy. Làm tốt những phần này thường mang lại cải thiện rõ rệt hơn nhiều so với việc chỉ nâng cấp model.

Làm thế nào để tránh LLM bịa ra câu trả lời (hallucinations)?

Đây là một trong những vấn đề “kinh điển” của RAG: khi retrieval không tìm được thông tin, nhưng LLM vẫn cố trả lời và dẫn đến hallucination. Cách xử lý hiệu quả không nằm ở một kỹ thuật duy nhất, mà là kết hợp nhiều lớp kiểm soát trong pipeline.

Trước hết, cần ràng buộc rõ ở prompt: yêu cầu model chỉ trả lời dựa trên context, và nếu không tìm thấy thông tin thì phải nói “không có dữ liệu”. Điều này giúp giảm đáng kể việc model “bịa”, dù không loại bỏ hoàn toàn.

Tiếp theo là kiểm soát ngay từ bước retrieval bằng cách đặt threshold cho similarity score. Nếu tất cả các document retrieve được đều có độ liên quan thấp, hệ thống nên coi như “không có context hợp lệ” và không gửi vào LLM, mà trả về fallback response (ví dụ: “không tìm thấy thông tin phù hợp”).

Một cách khác là dùng answer verification hoặc self-check. Sau khi LLM generate câu trả lời, có thể chạy thêm một bước kiểm tra xem câu trả lời có thực sự được support bởi context hay không (ví dụ: hỏi lại model hoặc dùng một classifier). Nếu không, thì reject hoặc yêu cầu trả lời lại.

Ngoài ra, việc cải thiện retrieval quality (better chunking, hybrid retrieval, reranking) cũng gián tiếp giảm hallucination, vì khi context đúng và đủ, model ít có xu hướng “đi chệch”.

Share Quang

Tóm lại, để hạn chế hallucination khi không có context, cần:

Ép model “biết nói không” (prompting)
Phát hiện khi retrieval fail (threshold, filtering)
Kiểm tra lại câu trả lời (verification)

Thay vì tin tưởng hoàn toàn vào LLM, hệ thống nên chủ động kiểm soát để đảm bảo chỉ trả lời khi thực sự có dữ liệu hỗ trợ.

Các lỗi phổ biến trong hệ thống RAG và cách debug

Trong các hệ thống RAG, failure hiếm khi đến từ một điểm duy nhất mà thường xuất phát từ nhiều bước khác nhau trong pipeline. Vì vậy, cách debug hiệu quả nhất là tách hệ thống thành từng stage rõ ràng như ingestion, retrieval, context construction và generation, sau đó kiểm tra từng phần một cách độc lập.

Ở bước ingestion, lỗi thường đến từ việc xử lý dữ liệu không chính xác. Ví dụ như parsing PDF bị sai, làm mất bảng biểu hoặc cấu trúc tài liệu, hoặc chunking không hợp lý khiến thông tin bị cắt rời khỏi ngữ cảnh. Khi gặp các câu trả lời sai, một cách debug hiệu quả là trace ngược lại từ câu trả lời → context → document gốc để xem dữ liệu đầu vào có bị lỗi hay thiếu sót không.

Ở bước retrieval, failure phổ biến nhất là không lấy được đúng context. Điều này có thể do embedding model không phù hợp, chunk quá dài hoặc quá ngắn, hoặc query không match với cách dữ liệu được viết. Cách debug đơn giản nhưng rất hiệu quả là log ra top-K documents được retrieve và tự đánh giá xem chúng có thực sự liên quan hay không. Nếu không, cần điều chỉnh retrieval strategy như hybrid search hoặc thêm reranking.

Ngay cả khi retrieval đúng, hệ thống vẫn có thể fail ở bước context construction. Ví dụ, context quá dài bị truncate, chứa nhiều thông tin nhiễu, hoặc không làm nổi bật phần quan trọng. Khi đó, nên inspect trực tiếp prompt cuối cùng gửi vào LLM để kiểm tra xem thông tin có rõ ràng và đủ để trả lời hay không.

Ở bước generation, lỗi thường biểu hiện dưới dạng hallucination — khi LLM tạo ra câu trả lời không có trong context. Nguyên nhân thường là do prompt chưa đủ chặt hoặc hệ thống vẫn generate ngay cả khi retrieval không tìm được thông tin phù hợp. Cách debug là so sánh câu trả lời với context, kiểm tra xem nó có thực sự được support hay không, và bổ sung các ràng buộc rõ ràng trong prompt.

Cuối cùng, một cách debug quan trọng trong thực tế là trace end-to-end. Debug theo kiểu End-to-End (quan trọng nhất)

Context nào đã được dùng?
Context đó đến từ document nào?
Document được chunk ra sao?
Retrieval có bỏ sót document tốt hơn không?

Bug thực tế sẽ lộ ra khi trace theo cách này, trong thực tế, RAG fail thường không phải do LLM mà do retrieval + dữ liệu + pipeline design. Hệ thông cần thiết kế debug tốt, tức là quan sát được từng bước trong pipeline.

Cách thiết kế citations and source attribution

Trong một hệ thống RAG, citations và source attribution được implement nhằm đảm bảo câu trả lời có thể kiểm chứng và tăng độ tin cậy cho người dùng. Cách làm hiệu quả bắt đầu ngay từ bước ingestion: mỗi chunk tài liệu không chỉ chứa nội dung mà còn đi kèm metadata như document ID, tiêu đề, số trang, section hoặc URL. Những thông tin này đóng vai trò như “định danh nguồn” để có thể trace ngược lại sau này.

Thanks for reading! This post is public so feel free to share it.

Khi thực hiện retrieval, hệ thống không chỉ lấy nội dung của các chunk liên quan mà còn giữ lại toàn bộ metadata tương ứng. Ở bước augmentation, các chunk này được đưa vào prompt cùng với thông tin nguồn, và LLM được hướng dẫn rõ ràng phải trả lời dựa trên context và kèm theo trích dẫn. Một pattern phổ biến là đánh số các chunk (ví dụ [1], [2], [3]) ngay trong prompt để model dễ tham chiếu khi generate câu trả lời.

Sau khi LLM sinh câu trả lời, hệ thống có thể thực hiện thêm bước post-processing để hiển thị citation một cách rõ ràng hơn, ví dụ gắn link, highlight đoạn text gốc, hoặc nhóm các nguồn theo mức độ liên quan.

Điểm quan trọng nhất là đảm bảo traceability và consistency: mỗi citation phải thực sự liên quan đến nội dung đã dùng để generate câu trả lời. Nếu làm tốt, người dùng không chỉ nhận được câu trả lời, mà còn biết chính xác thông tin đó đến từ đâu và có thể tự kiểm chứng khi cần.

Làm thế nào để scale một hệ thống với hàng chục triệu documents?

Khi scale một hệ thống RAG lên hàng chục triệu documents, vấn đề cốt lõi là giữ được latency thấp trong khi vẫn đảm bảo chất lượng retrieval. Ở phase ingestion, cần thiết kế pipeline phân tán và xử lý theo batch để embedding dữ liệu ở quy mô lớn, thường dùng queue + worker để scale ngang. Dữ liệu sau đó được lưu trong vector database hỗ trợ sharding, giúp chia nhỏ index trên nhiều node thay vì giữ một khối lớn, từ đó tăng khả năng mở rộng.

Ở bước retrieval, không thể dùng tìm kiếm chính xác toàn bộ mà phải chuyển sang Approximate Nearest Neighbor (ANN) để trade-off một chút accuracy lấy tốc độ. Một pattern rất phổ biến là multi-stage retrieval: đầu tiên retrieve nhanh một tập candidate lớn (top vài trăm) bằng ANN hoặc hybrid search, sau đó dùng reranking (cross-encoder hoặc LLM) để chọn ra top-K chất lượng cao. Cách này giúp hệ thống vừa nhanh vừa giữ được độ chính xác cần thiết.

Ngoài ra, khi hệ thống lớn dần, caching trở thành yếu tố bắt buộc: từ cache embedding, cache kết quả retrieval cho đến semantic caching cho câu trả lời. Song song đó là việc partition dữ liệu theo domain hoặc thời gian để thu hẹp không gian tìm kiếm. Cuối cùng, cần có monitoring liên tục (latency, recall@K, hit rate) để phát hiện sớm khi chất lượng giảm do dữ liệu tăng hoặc thay đổi distribution.

Ở quy mô này, RAG không còn là một feature AI đơn lẻ mà gần như trở thành một search system phân tán. Thành công phụ thuộc nhiều vào kiến trúc dữ liệu, indexing và retrieval pipeline hơn là chỉ nâng cấp model.

Kết luận

Thiết kế một hệ thống RAG luôn là bài toán cân bằng giữa nhiều yếu tố, vì việc tối ưu một chiều thường sẽ ảnh hưởng tiêu cực đến chiều khác.

Latency và Accuracy: nếu retrieve nhiều document hơn và áp dụng reranking kỹ, chất lượng câu trả lời sẽ tốt hơn, nhưng thời gian phản hồi cũng tăng lên đáng kể. Ngược lại, nếu tối ưu cho tốc độ, hệ thống có thể bỏ sót những context quan trọng.

Chunk size và context quality: Chunk nhỏ giúp tăng độ chính xác khi retrieval vì mỗi đoạn mang thông tin cụ thể hơn, nhưng lại dễ mất ngữ cảnh tổng thể. Ngược lại, chunk lớn giữ được ý nghĩa đầy đủ hơn nhưng làm giảm khả năng match chính xác với query. Việc chọn kích thước chunk phù hợp thường phụ thuộc vào loại dữ liệu và use case cụ thể.

Cost và quality: Sử dụng embedding model mạnh hơn, reranker tốt hơn hoặc LLM lớn hơn sẽ cải thiện chất lượng, nhưng chi phí tính toán và vận hành cũng tăng lên đáng kể. Trong production, thường phải tìm điểm cân bằng để đảm bảo hệ thống vừa đủ tốt mà vẫn tối ưu chi phí.

Freshness và stability: Việc cập nhật dữ liệu liên tục giúp hệ thống luôn có thông tin mới, nhưng cũng làm tăng chi phí re-indexing và có thể ảnh hưởng đến độ ổn định của retrieval. Ngược lại, giữ index ổn định giúp hệ thống predictable hơn nhưng có nguy cơ bị lỗi thời.

System complexity và maintainability: Thêm nhiều bước như hybrid retrieval, reranking, caching hay verification sẽ giúp hệ thống mạnh hơn, nhưng cũng khiến pipeline phức tạp, khó debug và khó vận hành hơn. Một thiết kế tốt không phải là dùng mọi kỹ thuật có thể, mà là chọn đủ những gì cần thiết để đạt mục tiêu của bài toán.

Hiểu đúng về LLM: từ cách hoạt động đến bài toán context trong thực tế (p1)

Quang — Wed, 25 Mar 2026 09:27:59 GMT

Trong làn sóng GenAI hiện nay, rất nhiều người nói về Large Language Models (LLMs) — nhưng không phải ai cũng thực sự hiểu cách chúng hoạt động và quan trọng hơn: làm sao để sử dụng chúng hiệu quả trong production.

Bài viết này không đi sâu vào toán học hay kiến trúc Transformer chi tiết. Thay vào đó, chúng ta sẽ tập trung vào góc nhìn thực tế của một AI Engineer:

LLM thực sự hoạt động như thế nào?
Làm sao để điều khiển output của nó?
Context window giới hạn bạn ra sao?
Và quan trọng nhất: làm sao quản lý memory & context hiệu quả?

Thanks for reading! This post is public so feel free to share it.

LLM hoạt động như thế nào?

Ở mức tổng quan, large language models (LLMs) hoạt động như những hệ thống dự đoán token tiếp theo dựa trên xác suất. Khi nhận input, văn bản sẽ được chia thành các token, sau đó được chuyển thành vector và đưa qua nhiều lớp Transformer sử dụng cơ chế attention để nắm bắt mối quan hệ giữa các phần trong câu. Tại mỗi bước, mô hình sẽ tính toán phân phối xác suất cho token tiếp theo và chọn ra một token phù hợp để tiếp tục sinh ra chuỗi văn bản. Quá trình này lặp lại cho đến khi hoàn thành câu trả lời. Điều quan trọng cần hiểu là LLM không thực sự “hiểu” nội dung như con người, mà chỉ học và tái hiện lại các pattern ngôn ngữ dựa trên dữ liệu huấn luyện.

Ví dụ:

Khi bạn nhập một câu prompt, LLM sẽ:

Chuyển text thành tokens
Biến tokens thành vector (embedding)
Dùng cơ chế attention để hiểu mối quan hệ giữa các token
Dự đoán token tiếp theo với xác suất cao nhất
Lặp lại quá trình này để tạo thành câu trả lời

Điều quan trọng cần hiểu là:

LLM không “hiểu” theo nghĩa con người — nó chỉ học pattern từ dữ liệu.

Các tham số nào được dừng để điều khiển đầu ra của LLM

Việc điều khiển output của LLM không phải là ra lệnh trực tiếp, mà là điều chỉnh cách mô hình lấy mẫu từ phân phối xác suất của nó. Các tham số như temperature ảnh hưởng đến độ ngẫu nhiên: giá trị thấp khiến output ổn định và dễ đoán hơn, trong khi giá trị cao làm tăng tính sáng tạo nhưng cũng tăng rủi ro sai sót.

Ví dụ, với giá trị:

Thấp (0–0.3): Thường được dùng trong các ứng dụng như chatbot, Q&A
Cao (0.7–1.0): sáng tạo, nhưng rủi ro, rất thích hợp khi creative writing

Tham số top-p (nucleus sampling) giới hạn việc lựa chọn token trong một tập hợp có tổng xác suất nhất định, giúp cân bằng giữa độ đa dạng và độ tin cậy.

Ngoài ra, các tham số như max tokens kiểm soát độ dài output, còn frequency hoặc presence penalty giúp giảm tình trạng lặp lại. Trong thực tế, việc tuning các tham số này luôn là bài toán trade-off giữa độ chính xác, tính đa dạng và chi phí.

LLMs quản lý context như thế nào, và các giới hạn thực tế của context window?

LLMs xử lý thông tin dựa trên một context window cố định, tức là toàn bộ dữ liệu mà mô hình có thể “nhìn thấy” trong một lần suy luận. Tất cả input, bao gồm prompt và lịch sử hội thoại, đều phải nằm trong giới hạn này. Tuy nhiên, context window mang lại nhiều ràng buộc thực tế.

Thứ nhất, nó giới hạn lượng thông tin có thể đưa vào, khiến việc xử lý dữ liệu lớn trở nên khó khăn.

Thứ hai, chi phí và độ trễ tăng lên đáng kể khi context dài hơn, do độ phức tạp tính toán của attention.

Ngoài ra, mô hình thường không phân bổ sự chú ý đồng đều, mà có xu hướng tập trung vào phần đầu và cuối, dẫn đến hiện tượng “lost in the middle” khi thông tin ở giữa bị bỏ qua. Những hạn chế này khiến việc quản lý context trở thành một bài toán quan trọng trong thiết kế hệ thống.

Tóm lại, bạn không thể giải quyết bài toán dữ liệu bằng cách “nhét thêm context” vào prompt.

Làm thế nào đẻ quản lý memory và context hiệu quả

Để quản lý memory và context hiệu quả, cần nhìn nhận rằng context window chỉ phù hợp cho thông tin ngắn hạn, trong khi dữ liệu dài hạn phải được xử lý bên ngoài mô hình.

Một cách tiếp cận phổ biến là sử dụng Retrieval-Augmented Generation (RAG), trong đó dữ liệu được lưu trữ trong các hệ thống như vector database và chỉ những phần liên quan nhất mới được truy xuất vào context khi cần.

Bên cạnh đó, các kỹ thuật như tóm tắt hội thoại giúp giảm kích thước context nhưng vẫn giữ được ý chính, và sliding window giúp duy trì các tương tác gần nhất mà không làm quá tải mô hình. Đổi lại là đôi khi cũng bị mất chi tiết quan trọng của cuộc hội thoại.

Trong thực tế, các hệ thống hiệu quả thường kết hợp nhiều chiến lược khác nhau để cân bằng giữa độ chính xác, chi phí và hiệu năng. Về bản chất, quản lý context không chỉ là vấn đề của LLM, mà là bài toán rộng hơn về retrieval và tối ưu hóa thông tin trong hệ thống.

Serializability là gì và vì sao nó được dùng trong các ứng dụng tài chính

Quang — Thu, 26 Feb 2026 07:02:55 GMT

Serializable (Serializability isolation level) là mức cô lập mạnh nhất trong các isolation level tiêu chuẩn. Một lịch thực thi được gọi là serializable nếu kết quả cuối cùng của nó tương đương với việc các transaction chạy tuần tự, từng cái một, theo một thứ tự nào đó. Điều quan trọng ở đây không phải là chúng thực sự chạy tuần tự, mà là kết quả phải giống như tuần tự. Nhờ tính chất này, lập trình viên có thể suy nghĩ về logic business theo cách đơn giản: “các transaction xảy ra lần lượt”, dù thực tế hệ thống đang chạy song song.

Tại sao lại cần serializability khi đã có read-committed và snapshot ?

Ở các mức như Read Committed hay Snapshot Isolation, vẫn có những tình huống mà logic business bị phá vỡ dù không có lỗi cú pháp hay crash. Ví dụ điển hình là write skew: hai transaction cùng đọc một điều kiện hợp lệ, sau đó cập nhật ở hai nơi khác nhau và vô tình làm hệ thống rơi vào trạng thái không mong muốn. Serializable loại bỏ những trường hợp như vậy bằng cách đảm bảo rằng mọi xung đột tiềm ẩn đều được kiểm soát. Nói cách khác, nếu một lịch thực thi không thể sắp xếp lại thành tuần tự hợp lệ, hệ thống sẽ buộc một transaction phải abort.

Thanks for reading! This post is public so feel free to share it.

Two-Phase Look (2PL)

Các database system thường dùng thuật toán Two-Phase Look (2PL) để cài đặt serializability isolation level. Trong phần này chúng ta sẽ tìm hiểu chi tiết hơn về 2PL.

Ý tưởng của 2PL rất đơn giản, mỗi transaction phải tuân theo hai pha — pha mở rộng (chỉ xin lock, không nhả) và pha thu hẹp (chỉ nhả lock, không xin thêm). Quy tắc này đảm bảo rằng nếu có xung đột đọc/ghi giữa các transaction, thứ tự lock sẽ quyết định thứ tự “tuần tự hoá” của chúng. Nhờ đó, toàn bộ hệ thống duy trì được tính serializable mà không cần phân tích toàn bộ lịch thực thi sau khi nó xảy ra.

Nếu transaction A đã đọc một object và transaction B muốn ghi vào object đó, thì B phải đợi cho đến khi A commit hoặc abort thì mới được tiếp tục. (Điều này đảm bảo rằng B không thể thay đổi object một cách bất ngờ “sau lưng” A.)
Nếu transaction A đã ghi vào một object và transaction B muốn đọc object đó, thì B phải đợi cho đến khi A commit hoặc abort thì mới được tiếp tục. (Việc đọc một phiên bản cũ của object, như trong Hình 8-4, là không được chấp nhận dưới 2PL.)

Trong 2PL, người ghi (writer) không chỉ chặn những writer khác mà còn chặn cả reader, và ngược lại. Khẩu quyết “reader không bao giờ chặn writer, và writer không bao giờ chặn reader” của snapshot isolation chính là điểm khác biệt quan trọng giữa snapshot isolation và 2PL.

Trong 2PL, có 2 loại lock:

S lock là viết tắt của Shared lock, tức là “khóa dùng chung”. Transaction sẽ xin S lock khi nó chỉ muốn đọc dữ liệu mà không sửa đổi gì. Chú ý, nhiều transaction có thể cùng giữ S lock trên cùng một dòng dữ liệu.
X lock là viết tắt của Exclusive lock, tức là “khóa độc quyền”. Transaction xin X lock khi nó muốn ghi dữ liệu (update, delete).
Khác với S lock, X lock mang tính độc quyền hoàn toàn:
- Không ai khác được đọc
- Không ai khác được ghi
Chỉ có đúng một transaction được giữ X lock tại một thời điểm.

Hãy nhìn vào hình vẽ ở trên để xem cách 2PL hoạt động. Two-Phase Locking (2PL) theo trục thời gian của một transaction. Ở nửa đầu (Growing Phase), transaction chỉ được xin thêm lock và không được nhả bất kỳ lock nào, nên số lượng lock tăng dần theo thời gian. Đến một thời điểm gọi là Locked Point, transaction đã xin đủ tất cả các lock cần thiết. Sau đó bước sang nửa sau (Shrinking Phase), nó chỉ được nhả lock và không được xin thêm lock mới, nên số lock giảm dần cho đến khi kết thúc. Quy tắc “đã nhả lock thì không xin thêm” chính là yếu tố cốt lõi giúp 2PL đảm bảo tính serializability.

Ví dụ về cách 2PL hoạt động

Giả sử chúng ta có một bảng Account, trong đó có một dòng dữ liệu đại diện cho tài khoản A với số dư là 1.000$. Có hai transaction đang hoạt động đồng thời:

T1: chỉ muốn đọc số dư để tính lãi suất.
T2: muốn cập nhật số dư (ví dụ trừ tiền).

Khi T1 bắt đầu và thực hiện truy vấn đọc, nó sẽ xin một S lock (Shared lock) trên dòng dữ liệu của tài khoản A. Vì đây là khóa chia sẻ, nên nhiều transaction khác cũng có thể xin S lock để đọc cùng lúc. Trong thời điểm này, việc đọc là hoàn toàn an toàn vì không có thay đổi nào xảy ra.

Tuy nhiên, nếu T2 muốn cập nhật số dư, nó cần xin một X lock (Exclusive lock). Vấn đề là X lock không tương thích với S lock. Vì T1 đang giữ S lock, nên T2 buộc phải chờ cho đến khi T1 hoàn thành và nhả lock. Chỉ khi đó T2 mới được cấp X lock và thực hiện cập nhật.

Ngược lại, nếu T2 đã xin X lock trước và đang cập nhật dữ liệu, thì mọi transaction khác – kể cả những transaction chỉ muốn đọc – cũng phải chờ. Bởi vì khi một transaction đang ghi, nó cần quyền truy cập độc quyền hoàn toàn để đảm bảo dữ liệu không bị thay đổi giữa chừng.

Từ ví dụ này có thể rút ra một nguyên tắc rất đơn giản: nhiều người có thể cùng đọc một dữ liệu, nhưng khi có người muốn ghi, họ phải được ở một mình.

Nhược điểm của 2 PL

Nhược điểm lớn nhất của 2PL là hiệu năng kém. So với các mức isolation yếu hơn, throughput thấp hơn và thời gian phản hồi chậm hơn đáng kể.

Nguyên nhân một phần do chi phí quản lý lock, nhưng quan trọng hơn là vì giảm mức độ đồng thời (concurrency). Nếu hai transaction có khả năng gây race condition, một trong hai bắt buộc phải chờ transaction còn lại hoàn thành.

Ví dụ, nếu có một transaction cần đọc toàn bộ bảng (backup, query phân tích, kiểm tra dữ liệu), nó phải giữ shared lock trên cả bảng. Điều này khiến:

Nó phải chờ tất cả transaction đang ghi hoàn thành.
Trong lúc nó đọc (có thể rất lâu với bảng lớn), mọi transaction muốn ghi đều bị block.

Kết quả là database gần như không thể ghi dữ liệu trong một khoảng thời gian dài.

Vì vậy, hệ thống dùng 2PL thường có độ trễ không ổn định, đặc biệt khi có contention. Chỉ một transaction chậm hoặc giữ quá nhiều lock cũng có thể làm cả hệ thống trì trệ. Người ta thường dùng timeout và giám sát query chậm để hạn chế vấn đề này.

Ngoài ra, deadlock xảy ra thường xuyên hơn trong 2PL serializable. Khi deadlock xảy ra, một transaction phải bị abort và chạy lại từ đầu, gây lãng phí tài nguyên nếu tình trạng này lặp lại nhiều lần.

Kết luận

Hi vọng qua bài viết này bạn đã có cái nhìn đầy đủ hơn về sẻ Serializable và 2PL trong database system. Nếu bạn có thắc mắc gì, đừng ngần ngại để lại comment bên dưới để cùng thảo luận.

Nguồn tham khảo

Designing Data-Intensive Applications – Cuốn sách gần như bắt buộc phải đọc nếu bạn làm backend hoặc hệ thống phân tán. Phần nói về isolation level và MVCC cực kỳ sáng sủa.
A Critique of ANSI SQL Isolation Levels (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf) – Bài paper kinh điển phân tích vì sao định nghĩa isolation trong SQL chưa đủ chặt và Snapshot Isolation thực sự khác Serializable ở điểm nào.
PostgreSQL Documentation (https://www.postgresql.org/docs/current/transaction-iso.html) – Nếu bạn muốn xem một hệ thống thật sự triển khai MVCC như thế nào (xmin, xmax, vacuum, visibility rules…), đọc tài liệu chính thức sẽ rất đáng giá.

Snapshot Isolation Level

Quang — Wed, 25 Feb 2026 04:34:06 GMT

Trong bài trước, chúng ta đã tìm hiểu về Read Committed và những vấn đề có thể phát sinh khi sử dụng mức cô lập này. Ở bài viết này, chúng ta sẽ tiếp tục với một isolation level cao hơn: Snapshot Isolation. Snapshot Isolation có thể tạm dịch là “cô lập theo ảnh chụp dữ liệu”. Ngay từ tên gọi, ta có thể hình dung rằng mỗi transaction sẽ quan sát database tại một thời điểm xác định trong quá khứ, thay vì theo dõi những thay đổi đang diễn ra theo thời gian thực. Một “snapshot” ở đây có thể hiểu là một phiên bản hoàn chỉnh của database tại một thời điểm cụ thể.

Tại sao lại cần snapshot khi đã có Read-committed?

Snapshot Isolation ra đời để giải quyết một vấn đề rất cụ thể nhưng cực kỳ nguy hiểm trong hệ thống concurrent: việc đọc dữ liệu không nhất quán trong cùng một transaction. Ở mức Read Committed, mỗi câu lệnh có thể nhìn thấy database tại một thời điểm khác nhau, dẫn đến việc logic tính toán dựa trên nhiều dòng dữ liệu có thể bị lệch. Điều này không vi phạm atomicity, nhưng lại phá vỡ giả định rằng “những gì tôi đọc trong transaction này thuộc về cùng một trạng thái của hệ thống”. Snapshot Isolation đảm bảo rằng toàn bộ transaction sẽ làm việc trên một ảnh chụp cố định của dữ liệu. Nhờ vậy, mọi quyết định trong transaction đều dựa trên một nền tảng nhất quán.

Làm thế nào database có thể đảm bảo transaction có thể đọc dữ liệu ở một “snapshot”?

Điểm cốt lõi của Snapshot Isolation là việc cố định thời điểm quan sát dữ liệu ngay khi transaction bắt đầu. Khi một transaction được khởi tạo, hệ thống ghi nhận một mốc thời gian logic và từ đó trở đi chỉ cho phép transaction này nhìn thấy những thay đổi đã commit trước mốc đó. Những thay đổi xảy ra sau khi transaction bắt đầu sẽ không được hiển thị trong quá trình đọc. Điều này loại bỏ hoàn toàn khả năng đọc dữ liệu từ hai thời điểm khác nhau trong cùng một transaction. Nhờ cơ chế đó, các phép tính tổng, kiểm tra điều kiện business, hay xử lý logic phức tạp đều trở nên đáng tin cậy hơn.

Cơ chế kỹ thuật đứng sau Snapshot Isolation là Multi-Version Concurrency Control (MVCC). Thay vì ghi đè dữ liệu cũ khi có update, hệ thống tạo ra một phiên bản mới của dòng dữ liệu và giữ lại phiên bản cũ trong một khoảng thời gian. Mỗi phiên bản được gắn thông tin về transaction đã tạo ra nó và trạng thái commit tương ứng. Khi một transaction đọc dữ liệu, database sẽ dựa trên snapshot của transaction đó để quyết định phiên bản nào là “visible”. Cách làm này cho phép nhiều transaction tồn tại song song mà không cần khóa dữ liệu theo cách truyền thống.

MVCC mang lại một lợi ích quan trọng là giảm thiểu việc chặn lẫn nhau giữa các transaction. Transaction đọc có thể tiếp tục truy cập các phiên bản cũ mà không cần chờ transaction ghi hoàn tất. Ngược lại, transaction ghi có thể tạo ra phiên bản mới mà không làm gián đoạn những transaction đang đọc. Điều này giúp hệ thống đạt được mức độ song song cao trong khi vẫn đảm bảo tính nhất quán ở cấp độ transaction. Nhờ đó, Snapshot Isolation thường được xem là sự cân bằng hợp lý giữa hiệu năng và độ an toàn dữ liệu.

Minh hoạ cách MVCC hoạt động

Thay vì ghi đè trực tiếp giá trị cũ, mỗi lần UPDATE hệ thống sẽ tạo ra một phiên bản mới của dòng dữ liệu, trong khi các phiên bản cũ vẫn được giữ lại. Ở ví dụ này, số dư ban đầu là 500 (Version 1), sau đó được cập nhật thành 400 (Version 2), rồi tiếp tục thành 450 (Version 3). Điều quan trọng là Version 1 và Version 2 không bị xoá ngay lập tức; chúng vẫn tồn tại để phục vụ các transaction đang chạy với snapshot cũ hơn. Nhờ cơ chế này, nhiều transaction có thể đọc dữ liệu song song mà không chặn nhau, vì mỗi transaction sẽ nhìn thấy phiên bản phù hợp với thời điểm nó bắt đầu.

Visibility rules for observing a consistent snapshot

Bạn có thể thắc mắc làm sao để quyết định một transaction thấy database ở thời điểm nào, vì cùng một lúc database có thể có nhiều version khác nhau. Ví dụ như bạn có thể có nhiều ảnh chụp chân dung cho các mốc thời gian khác nhau. Do đó, chúng ta có quy tắc để quyết định một transaction sẽ nhìn database như thế nào. Quy tắc đó như sau:

Khi một transaction bắt đầu, database sẽ tạo một danh sách tất cả các transaction khác đang chạy tại thời điểm đó (tức là chưa commit hoặc chưa bị abort). Mọi thay đổi mà các transaction này đã ghi sẽ bị bỏ qua, ngay cả khi sau đó chúng commit thành công. Nhờ vậy, ứng dụng sẽ nhìn thấy một snapshot nhất quán, không bị ảnh hưởng bởi việc một transaction khác commit trong lúc nó đang chạy.
Mọi thay đổi được thực hiện bởi các transaction có transaction ID lớn hơn (tức là những transaction bắt đầu sau transaction hiện tại và vì thế không nằm trong danh sách các transaction đang chạy ban đầu) cũng sẽ bị bỏ qua, bất kể chúng đã commit hay chưa.
Mọi thay đổi được thực hiện bởi các transaction đã bị abort đều bị bỏ qua, bất kể việc abort xảy ra khi nào. Điều này có lợi ở chỗ khi một transaction bị hủy, chúng ta không cần phải lập tức xóa các dòng dữ liệu mà nó đã ghi xuống storage, vì visibility rule đã tự động loại chúng ra khỏi kết quả truy vấn. Quá trình dọn dẹp (garbage collection) có thể xử lý chúng sau.
Tất cả những thay đổi còn lại sẽ được coi là hợp lệ và hiển thị cho các truy vấn của ứng dụng.

Kết luận

Hi vọng qua bài viết này bạn đã có cái nhìn đầy đủ hơn về snapshot isolation level trong database system. Nếu bạn có thắc mắc gì, đừng ngần ngại để lại comment bên dưới để cùng thảo luận.

Nguồn tham khảo

Designing Data-Intensive Applications – Cuốn sách gần như bắt buộc phải đọc nếu bạn làm backend hoặc hệ thống phân tán. Phần nói về isolation level và MVCC cực kỳ sáng sủa.
A Critique of ANSI SQL Isolation Levels (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf) – Bài paper kinh điển phân tích vì sao định nghĩa isolation trong SQL chưa đủ chặt và Snapshot Isolation thực sự khác Serializable ở điểm nào.
PostgreSQL Documentation (https://www.postgresql.org/docs/current/transaction-iso.html) – Nếu bạn muốn xem một hệ thống thật sự triển khai MVCC như thế nào (xmin, xmax, vacuum, visibility rules…), đọc tài liệu chính thức sẽ rất đáng giá.

Transaction là atomic. Nhưng dữ liệu bạn đọc vẫn có thể “lệch”.

Quang — Tue, 24 Feb 2026 10:10:30 GMT

Hồi mới tìm hiểu về transaction isolation, mình từng nghĩ rất đơn giản:

Nếu một transaction update A và B trong cùng một commit, thì người khác hoặc thấy cả hai thay đổi, hoặc không thấy gì cả. Làm gì có chuyện nửa cũ nửa mới?

Nghe hoàn toàn hợp lý.

Nhưng khi đào sâu vào Read Committed, mình nhận ra:
Atomic không đồng nghĩa với việc mọi thứ bạn đọc sẽ luôn “nhất quán”.

Và đó là lúc mọi thứ bắt đầu thú vị.

Một ví dụ tưởng chừng không thể xảy ra

Giả sử một user có hai tài khoản:

A = 500
B = 500
Tổng = 1000

Có một transaction đang chuyển 100 từ A sang B:

BEGIN;
UPDATE accounts SET balance = 400 WHERE id = ‘A’;
UPDATE accounts SET balance = 600 WHERE id = ‘B’;
COMMIT;

Rõ ràng là atomic.

Hoặc cả hai update cùng commit, hoặc không cái nào.

Bây giờ, cùng lúc đó, một transaction khác đọc số dư:

BEGIN;
SELECT balance FROM accounts WHERE id = ‘A’;
SELECT balance FROM accounts WHERE id = ‘B’;
COMMIT;

Câu hỏi là:

Liệu transaction đọc này có thể thấy:

A = 400
B = 500

Tổng = 900?

Nghe sai sai đúng không?

Nhưng với Read Committed, điều đó hoàn toàn có thể xảy ra.

Vấn đề nằm ở chỗ… snapshot

Điểm mấu chốt mà mình từng bỏ qua là:

Ở Read Committed, mỗi câu SQL sẽ nhìn database tại thời điểm nó bắt đầu.

Nghĩa là trong cùng một transaction, hai câu SELECT có thể nhìn hai “ảnh chụp” khác nhau của database.

Ví dụ timeline có thể diễn ra như sau:

T1 bắt đầu chuyển tiền
T1 update A
T2 SELECT A (lúc này T1 chưa commit → vẫn thấy 500)
T1 update B
T1 commit
T2 SELECT B (bây giờ đã commit → thấy 600)

Kết quả T2 thấy:

A = 500
B = 600

Tổng = 1100

Hoặc nếu thứ tự khác một chút, có thể ra 900.

Không có dirty read.

Không có commit nửa chừng.

Chỉ đơn giản là T2 không đọc cùng một snapshot.

Atomicity không cứu bạn ở đây

Đây là chỗ mình từng nhầm.

Atomicity đảm bảo transaction kia không commit nửa vời.

Nhưng isolation level mới quyết định transaction của bạn nhìn thế giới như thế nào.

Read Committed chỉ đảm bảo:

Không đọc dữ liệu chưa commit.

Nó không đảm bảo:

Bạn sẽ thấy một trạng thái logic nhất quán trong suốt transaction của mình.

Snapshot Isolation thì khác gì?

Với Repeatable Read (Snapshot Isolation), khi bạn BEGIN, database chụp một snapshot cố định.

Tất cả các câu SELECT sau đó đều nhìn snapshot đó.

Dù giữa chừng có ai commit thay đổi, bạn vẫn thấy cùng một trạng thái ban đầu.

Không có chuyện tổng tiền “nhảy” giữa hai lần SELECT.

Đây là sự khác biệt rất quan trọng:

Read Committed = nhất quán theo từng câu lệnh
Snapshot Isolation = nhất quán theo toàn bộ transaction

Tại sao điều này quan trọng?

Nếu bạn chỉ update một dòng đơn lẻ, có thể bạn sẽ không bao giờ nhận ra sự khác biệt.

Nhưng nếu bạn:

Tính tổng tiền
Check điều kiện business trước khi update
Làm inventory
Làm reporting
Làm hệ thống tài chính
Làm aggregation cho CDP

Thì việc đọc từ hai snapshot khác nhau có thể khiến logic của bạn sai.

Và những bug này cực kỳ khó tái hiện vì chúng phụ thuộc vào timing.

Bài học mình rút ra

Trước đây mình nghĩ transaction là “lá chắn” đủ mạnh.

Sau này mình hiểu ra:

Atomicity giúp bạn không commit nửa vời.
Isolation level quyết định bạn nhìn thấy thế giới ra sao.

Và Read Committed không hề “sai”.

Nó chỉ không mạnh như nhiều người nghĩ.

Hiểu rõ điều này giúp mình:

Debug những bug kỳ lạ dưới load cao
Thiết kế system an toàn hơn
Và quan trọng nhất: không đưa ra assumption sai về dữ liệu mình đang đọc

Concurrency không làm hệ thống hỏng ngay lập tức.

Nó chỉ chờ đúng timing.

Và đó là lúc mọi thứ bắt đầu thú vị.

Hy vọng bài viết này đã mang đến cho bạn một vài góc nhìn mới về isolation level trong database. Nếu có thắc mắc, đừng ngần ngại để lại bình luận – mình luôn sẵn sàng trao đổi thêm.

Nếu bạn thấy nội dung hữu ích, hãy subscribe để nhận thêm những chia sẻ chuyên sâu về kiến trúc hệ thống và microservices. Và nếu muốn ủng hộ mình có thêm động lực để viết nhiều hơn, bạn có thể mời mình một ly ☕ qua

Buy me a coffee

Cách thành phần cơ bản của Web 3

Quang — Mon, 22 Sep 2025 07:00:08 GMT

Bài viết lược dịch từ https://medium.com/coinmonks/the-ideology-of-web-3-38d3d9849e5a

Mình vừa mở trang Buy Me a Coffee ☕. Nếu bạn thấy những bài viết của mình hữu ích và ý nghĩa, có thể ủng hộ tác giả bằng một ly cà phê nhỏ để mình có thêm động lực chia sẻ nhiều hơn 💙.

Tạm gác lại loại bài về xây dựng ứng dụng data sensitive, hôm nay chúng ta sẽ tìm hiểu về Web3, bài viết này sẽ đi theo “chiều rộng”, nghĩa là lướt qua những công nghệ, khái niệm để từ đó xây dựng lên hệ sinh thái Web 3. Nhưng đầu tiên hãy cùng nhau trả lời câu hỏi, “Web 3 là gì?”, theo Wikipedia

"Web3 (còn được gọi là Web 3.0) là một ý tưởng về thế hệ mới của World Wide Web, trong đó tích hợp các khái niệm như phi tập trung, công nghệ blockchain và nền kinh tế dựa trên token."

Dựa vào định nghĩa trên, chúng ta có thể thấy rằng blockchain là nên tảng của Web3, giống như động cơ hơi đối với cuộc cánh mạng công nghiệp. Về bản chất, blockchain là một cấu trúc dữ liệu, giống như Link list hay Queue mà chúng ta được học ở lớp Cấu trúc dữ liệu và giải thuật (hi vọng bạn không ngủ quên khi học môn này!!!), với một số tính chất đặc biệt là chỉ cho phép thêm vào và có thể được mọi người quan sát công khai. Blockchain được xây dựng dựa trên sự kết hợp của: mật mã học (cryptography), hệ thống phân tán (distribution system) và lý thuyết trò chơi (game thoery).”

Mỗi lĩnh vực đóng vài trò quan trọng trong Web 3. Mật mã học giúp cho web 3 không cần phải tin tưởng vào một bên thứ ba trung gian, hệ thống phân tán giúp lưu trữ dữ liệu lâu dài và không thay đổi, lý thuyết trò chơi giúp Web 3 có tính tự nguyện

Phi tín nhiệm (Trustlessness) sức mạnh của mật mã học

Các thuật toán mã hóa, đặc biệt là mã hóa khóa công khai (public key encryption), giữ vai trò then chốt trong Web3. Chúng cho phép người dùng truyền dữ liệu một cách ẩn danh mà vẫn đảm bảo dữ liệu không bị rò rỉ hay chỉnh sửa.

Ngay cả trong các hệ thống tài chính tập trung truyền thống, mã hóa cũng đóng vai trò quan trọng bởi người dùng luôn có nhu cầu về sự riêng tư và an toàn. Hãy thử hình dung nếu ngân hàng của bạn không áp dụng bất kỳ biện pháp bảo mật nào: mọi người đều có thể theo dõi giao dịch của bạn và dễ dàng đánh cắp tiền trong tài khoản.

Với cách hệ thống tài chính phi tập trung, bảo mật lại càng trở thành một vấn đề cốt lõi, không có một thực thể trung tâm nào để bạn có thể khiếu nại, không có một trung tâm chăm sóc khách hàng nào để bạn gọi điện. Nếu tiền của bạn bị hack, thì coi như bạn mất tiền, mãi mãi. Đây là lý do vì sao Bitcoin đặc biết chú trọng vào vấn để bảo mật các giao dịch dựa vào mã hoá công khai. Bitcoin đặc biệt dựa vào các quy trình bảo mật hơn là tin vào con người. Tóm lại: Toán thì đáng tin tưởng hơn con người.

Quan trọng là sự phi tập trung chỉ là phương tiên, còn mục đích chính là sự phi tiến nhiệm. Sự phi tập trung không phải lúc nào cũng tốt. Chẳng hạn, chúng ta hãy nghĩ về chiếc xe tải thu gom rác chạy hàng ngày, khi nó chuyển sang phi tập trung, nghĩa là mọi người, hàng ngày phải tự lái xe mang rác ra khu vực xử lý. Đây là một sự bất tiện lớn và không cần thiết.

Thực chất, phi tập trung chỉ thực sự có ý nghĩa khi những lợi ích của tính phi tín nhiệm, tính lâu dài và tính tự nguyện vượt trội so với lợi thế kinh tế nhờ quy mô lớn. Lấy ví dụ về xe rác ở trên: ở đây, yếu tố phi tín nhiệm gần như không đặt ra, bởi chẳng ai hứng thú đi lục thùng rác của bạn để xem bên trong có gì, và thùng rác vốn cũng hiếm khi chứa những bí mật cá nhân. Vì vậy, rủi ro khi phải tin tưởng vào một thực thể tập trung như công ty thu gom rác là rất nhỏ, trong khi lợi ích kinh tế từ việc tập trung hóa lại vô cùng lớn.

Nhưng trong trường hợp dữ liệu ngân hàng và các giao dịch tài chính thì điều ngược lại mới đúng. Thực tế, không có nhiều lợi thế về kinh tế khi bạn gửi tiền vào một ngân hàng tập trung so với việc giữ tiền mặt trong két sắt riêng của mình (trừ việc bạn có được tiền lãi từ ngân hàng). Ngược lại, lại có rất nhiều người khao khát chiếm đoạt số tiền đó của bạn. Vì thế, việc phi tập trung hóa hệ thống tài chính để bảo đảm một mạng lưới không cần sự tin cậy mang lại những lợi ích vượt xa chi phí. Đó chính là lý do tại sao Bitcoin lại hợp lý khi được xây dựng như một dự án blockchain.

Sự bền vững - sức mạnh của hệ thống phi tập trung

Thực chất, lợi thế theo quy mô lớn cũng đồng thời là điểm yếu của quy mô. Single point of failure là một nút thắt khi phát triển về mặt quy mô. Việc lưu trữ thông tin trên nhiều máy tính khác nhau là ý tưởng chính của một hệ thống phi tập trung. Nhưng việc đó cũng đi kèm với rất nhiều vấn đề kỹ thuật, như chúng ta đã tìm hiểu ở các bài post trước của mình. Một vấn đề gây đau đầu cho các nhà thiết kế là bài toán “Byzantine Fault Tolerance”. Đó là một yêu cầu một hệ thống blockchain vẫn phải hoạt động tốt khi có tới 1/3 số node là “bad actor”. Điều đó đặt ra yêu cầu là mỗi giao dịch phải được validate bới ít nhất 2/3 số node trong mạng.

Một câu hỏi khác được đặt ra khi chúng ta đạt được tính bền vừng, điều gì lên được lưu trữ trên blockchain? Nếu trong ví dụ về xe thu gom rác, bạn không quan tâm lắm nếu rác nhà bạn biến mất, thực ra bạn phải trả tiền cho điều đó. Nhưng bạn sẽ không muốn tiền của bạn đột nhiên biến mất. Vì vậy, các giao dịch tài chính, chẳng hạn như sổ cái của Bitcoin, là một lĩnh vực hiển nhiên cần đến tính lâu dài. Ngoài ra, còn người còn muốn lưu trữ lâu dài các thử khác như: các bức ảnh, website cá nhân ..

Hiện tại, mọi thông tin đều được lưu trữ trên đĩa cứng, hoặc trên cloud của một công ty nào đó như Google hay Amazon. Điều gì sẽ xảy ra nếu ổ cứng của bạn bị hư, Google bị hack. Giải pháp của Web 2 là tin tưởng hoàn toàn vào một thực thể trung gian, các công ty công nghệ. Nhưng với Web 3, ý tưởng hoàn toàn khác. Nơi mọi thứ điều được phân tán tại các máy tính khác nhau.

Một dự án nổi tiếng để lưu trữ thông tin lâu dài trên Internet là Arweave. Với lời hứa lưu trữ thông tin vĩnh viễn trên cách máy tính phân tán với một khoản phí trả trước nhỏ. Trong khi Arweave được thiết kế dựa trên blockchain, nó thực sự mà nói không hẳn là blockchain. Blockchain là một cấu trúc dữ liệu mà một node được trỏ tới node kế tiếp. Còn ở Arweave, mỗi node có thể trỏ tới nhiều node khác nhau, gọi là “blockweave”. Sự thay đổi này giúp việc truy cập dữ liệu hiệu quả hơn.

Như bạn có thể đoán, Arweave và các giao thức “permaweb” phi tập trung khác (chẳng hạn như IPFS) có mối liên hệ tự nhiên với Non-Fungible Tokens, hay NFT. Nếu coi các tài sản permaweb trên Arweave và IPFS là một ngôi nhà, thì NFT chính là giấy chứng nhận quyền sở hữu của ngôi nhà đó. “Ngôi nhà” có thể được bất kỳ ai ghé thăm hoặc đi ngang qua nhìn thấy. Nhưng chỉ có chủ sở hữu mới nắm giữ giấy chứng nhận quyền sở hữu ngôi nhà. Và khi chủ sở hữu bán ngôi nhà cho người khác, họ không thay đổi gì đối với ngôi nhà; họ chỉ đơn giản là chuyển giao giấy chứng nhận cho người mua. Việc có một NFT giống như giấy chứng nhận quyền sở hữu giúp cho việc xác nhận quyền sở hữu và chuyển nhượng tài sản trở nên khả thi và được đảm bảo bằng mật mã. Do đó, NFT không chỉ là những “biển số ảo để khoe khoang của dân crypto”; chúng có công dụng thực tế như giấy chứng nhận quyền sở hữu tài sản kỹ thuật số. Nhưng một giấy chứng nhận chỉ có giá trị khi tài sản mà nó đại diện thực sự có giá trị. Vì vậy, hãy thử dùng NFT để liên kết tới những thứ khác ngoài hình ảnh một con khỉ.

Sự tự nguyện - sức mạnh của Lý thuyết trò chơi

Mọi người không trở thành một node trong mạng lưới chỉ vì sự tốt bụng trong trái tim. Họ làm điều đó vì tiền. Tính tự nguyện được thúc đẩy bởi lý thuyết trò chơi này thể hiện ở nhiều nơi, rõ ràng nhất là trong các mô hình đồng thuận “Proof of Stake” – nền tảng của nhiều blockchain hàng đầu như Ethereum, Polygon và Binance Smart Chain. Như trong infographic cho thấy, về cơ bản bạn sẽ “đặt cọc” một lượng coin nhất định, chẳng hạn 32 ETH trên Ethereum, vào mạng lưới để trở thành validator và tham gia đồng thuận. Nếu bạn là một nút trung thực trong mạng, bạn sẽ nhận được “phần thưởng staking”, khoảng ~10% APY. Ngược lại, nếu bị phát hiện là hành vi độc hại, số coin đã stake (32 ETH) của bạn sẽ bị “cắt giảm” (slashed), và bạn sẽ mất toàn bộ phần thưởng. Vì vậy, bạn có một động lực theo lý thuyết trò chơi để trở thành một nút trung thực trong mạng lưới.”

Kết luận

Web 3 vẫn đang ở giai đoạn sơ khai và còn một chặng đường dài phía trước. Tuy vậy, chúng ta đã có thể bắt đầu nhìn thấy tầm nhìn mang tính cách mạng về tương lai của nó, với một hệ tư tưởng dựa trên tính phi tín nhiệm (trustlessness), sự bền vững (permanence), và tính tự nguyện (voluntariness).”

Hy vọng bài viết này đã mang đến cho bạn một vài góc nhìn mới về Web 3 Nếu có thắc mắc, đừng ngần ngại để lại bình luận – mình luôn sẵn sàng trao đổi thêm.

– mình sẽ rất trân trọng!

Mô hình dữ liệu và ngôn ngữ truy vấn

Quang — Wed, 17 Sep 2025 10:53:13 GMT

Bài viết này lược dịch từ chương 2 cuốn sách “Designing data sensitive applications” của Martin Kleppmann

Mở đầu

Data model là cách mà các chúng ta nghĩ về các vấn đề mà chúng ta sẽ giải quyết. Mỗi data model được xây dựng dựa trên data model của lớp thấp hơn. Ví dụ:

Application developer: Nhìn các objects của thế giới thực và mô hình hoá thành cách objects hay data structure hay các API thảo tác trên các structure đó. Mỗi application sẽ có những structure khác nhau. Khi bạn muốn lưu trữ những structure này bạn phải sử dụng một “mô hình dữ liệu dùng chung” như JSON, XML, table trong relational database hay graph database.
Database developer: sẽ quyết định cách lưu trữ JSON/XML/Table/Graph thành từng byte trong memory, disk hay network. Các cách biểu diễn này cho phép data có thể truy vấn, tìm kiếm, thao tác hay xử lý theo nhiều cách khác nhau.
Hardware engineers: Ở level này, bạn sẽ quyết định cách biểu diễn từng byte dưới dạng các dòng điện, từ trường và nhiều thứ khác.

Một application phức tạp có thể build các API dựa trên các API khác, nhưng mà đều chung một ý tưởng: Trừu tượng hoá/đơn giản hoá sự phức tạp của các API ở level dưới bằng cách cung cấp một clean data model.

Có rất nhiều data model khác nhau, chỉ master một trong số chúng cũng đã rất khó (bạn thử đếm xem có bao nhiêu cuốn sách về chủ đề relational database).

Việc lựa chọn data model phù hợp với application của bạn là rất quan trọng.

Relational Model với Document Model

Data model nổi tiếng nhất có lẽ là SQL, dựa trên mô hình dữ liêu quan hệ, được phát triển từ những năm 1970. Data được lưu vào từng relations (bảng) mỗi relations có có tuple (dòng). Qua nhiều năm, với nhiều công nghệ khác, như network model, the hierarchical model hay XML databases… những relational model vẫn có chỗ đứng vững chắc trong các hệ thống ngày này, từ online publishing, discussion, social networking, ecommerce, games, software-as-a-service productivity applications và nhiều hơn nữa.

Không tương thích giữa object và relation

Nhà phát triển ứng dụng thường làm việc với các ngôn ngữ lập trình hướng đối tượng (OOP), trong khi dữ liệu lại được lưu trữ dưới dạng mô hình quan hệ. Vì vậy, cần có một lớp trung gian để ánh xạ giữa các đối tượng trong bộ nhớ và mô hình trong cơ sở dữ liệu. Các framework như Hibernate hay ActiveRecord có thể giúp giảm lượng mã cần viết cho việc ánh xạ này, nhưng vẫn không thể che giấu hoàn toàn những khác biệt giữa hai 2 models.

Trong ví dụ sau, một profile có thể được xác định bởi một ID duy nhất, first_name và last_name nhưng một profile có thê có nhiều positions, nhiều education record và nhiều contact info. Đó là mối quan hệ 1-n. Có nhiều cách để model mối quan hệ này.

Traditional SQL model: Đặt các thông tin như positions, education, and contact information sang một table khác và trỏ khoá ngoại về table user.

SQL model hiện đại cho phép data type của column là XML hoặc JSON, do đó cho phép “multi-valued” được chứa trong một dòng. Application có để đọc encoding string đó và tự decode nội dung. Tuy nhiên sẽ không thể sử dụng database để query nội dung trong các cột.

Thanks for reading! This post is public so feel free to share it.

Document-oriented database, chưa các object dạng document, ví dụ với profile như trên sẽ được lưu như sau:

{
    "user_id": 251,
    "first_name": "Bill",
    "last_name": "Gates",
    "summary": "Co-chair of the Bill & Melinda Gates Foundation. Active blogger.",
    "region_id": "us:91",
    "industry_id": 131,
    "photo_url": "/p/7/000/253/05b/308dd6e.jpg",
    "positions": [
        {
            "job_title": "Co-chair",
            "organization": "Bill & Melinda Gates Foundation"
        },
        {
            "job_title": "Co-founder, Chairman",
            "organization": "Microsoft"
        }
    ],
    "education": [
        {
            "school_name": "Harvard University",
            "start": 1973,
            "end": 1975
        },
        {
            "school_name": "Lakeside School, Seattle",
            "start": null,
            "end": null
        }
    ],
    "contact_info": {
        "blog": "http://thegatesnotes.com",
        "twitter": "http://twitter.com/BillGates"
    }
}

Many-to-One and Many-to-Many Relationships

Trong ví dụ trên, tại sao lại cần region_id hay industry_id mà không phải là free text region hay industry? Có một vài lý do để chuẩn hoá thông tin mà không cho user tự do nhập

Thống nhất tên và chính tả cho các profile khác nhau
Tránh nhầm lẫn (Ví dụ: nhiều thành phố có tên giống nhau)
Dễ dàng cập nhật, vì tên được lưu ở một nơi duy nhất, khi thay đổi chỉ cần thay đổi ở một nơi và tất cả mọi chỗ đều được cập nhật.
Search dễ dàng hơn

ID không có ý nghĩa với con người, con người chỉ quan tâm tới tên. Khi data lưu thông tin có ý nghĩa, nó có thể thay đổi trong tương lai. Và nếu data bị duplicate ở nhiều nơi, chúng ta phải thay đổi ở tất cả mọi nơi. Remove duplication là key idea trong data normalization.

Nhưng với mối quan hệ many-to-many, normalization không phù hợp trong document database. Ở relational database, việc lưu ID trỏ tới dòng ở table khác là hợp lý, vì co thể dễ dàng join query trong relation database. Nhưng join thường không được support hay support rất hạn chế trong document database.

Do đó, nếu database không support join, chúng ta thường tự join trên application level bằng cách viết nhiều câu query trong database và lưu data trong memory. Cần lưu ý có thể hiện tai ưng dụng của bạn hoạt động tốt trong một join-free document database, nhưng trong tương lai, với những yêu cầu mới, có thể sẽ không còn phù hợp nữa.

Relational Versus Document Databases Today

Document database:

Schema linh hoạt.
Tốt về performance cục bộ: Ví dụ website của bạn cần load thông tin về một entry, nếu data được lưu ở nhiều table khác nhau, việc join sẽ tốn thời gian
Gần với cấu trúc dữ liệu của application.

Relation database: Hỗ trợ join tốt hơn trong mối quan hệ: many-to-one and many-to-many

Ngôn ngữ truy vấn cho data

Ngôn ngữ truy vấn declarative và imperative

SQL tạo ra một ngôn ngữ truy vấn mới ngôn ngữ “khai báo” (declarative query language). Khác với các ngôn ngữ lập trình IMS and CODASYL, truy vấn cơ sở dữ liệu bằng cách sử dụng mã lệnh mệnh lệnh (imperative). Vậy sự khác biệt là gì?

Giải bạn có một danh sách các loài động vật (animals), và muốn lấy ra một list các “Sharks”. Ví dụ với một imperative ta có hàm như sau:


function getSharks() {
    var sharks = [];
    for (var i = 0; i < animals.length; i++) {
        if (animals[i].family === "Sharks") {
            sharks.push(animals[i]);
        }
    }
    return sharks;
}

Với SQL, một ngôn ngữ declarative sẽ có dạng:

SELECT * FROM animals WHERE family = 'Sharks';

Với imperative language, ta cần chỉ rõ cho máy tính cách thức thực hiện một tác vụ (HOW). Ví dụ như trong trường hợp trên, ta phải viết vòng lặp, so sánh các biến, rồi lưu kết quả vào một danh sách.

Trong khi đó, với declarative language, ta chỉ cần mô tả dữ liệu mà mình muốn lấy (WHAT). Chẳng hạn: “lấy dữ liệu có family là Sharks”, mà không cần quan tâm đến việc truy vấn được thực hiện như thế nào. Phần việc tối ưu hóa — như chọn chỉ mục hay chiến lược tìm kiếm — sẽ do hệ quản trị cơ sở dữ liệu quyết định.

Declarative language có lợi thế là dễ dàng song song hóa và cho phép hệ thống tự tối ưu truy vấn. Ngược lại, với imperative language, việc tối ưu là rất khó, bởi nó tập trung vào từng bước thực thi chi tiết thay vì mô tả mẫu dữ liệu mà ta cần.

MapReduce Querying

Là một programming model tạo bới Google cho xử lý một lượng lớn data, thành từng bulk, trong nhiều máy tính.

Ví dụ, hãy tưởng tượng bạn là một nhà sinh vật biển, và mỗi lần quan sát thấy động vật dưới đại dương, bạn lại thêm một bản ghi vào cơ sở dữ liệu. Giờ đây, bạn muốn tạo một báo cáo cho biết mỗi tháng bạn đã nhìn thấy bao nhiêu con cá mập.

Với PostgreSQL, bạn có thể viết một câu query như thế này:

SELECT date_trunc('month', observation_timestamp) AS observation_month, sum(num_animals) AS total_animals
FROM observations
WHERE family = 'Sharks' GROUP BY observation_month;

Câu query trên, đầu tiên sẽ lọc nhưng dòng có family = 'Sharks' sau đó group lại theo observation_month và tính tổng giá trị num_animals

Trong MongoDB’s MapReduce feature:

Giả sử chúng ta có dữ liệu như sau

{
    observationTimestamp: Date.parse("Mon, 25 Dec 1995 12:34:56 GMT"),
    family:     "Sharks",
    species:    "Carcharodon carcharias",
    numAnimals: 3
} 
{
    observationTimestamp: Date.parse("Tue, 26 Dec 1995 10:11:12 GMT"),
    family:     "Sharks",
    species:    "Delphinus Sharks",
    numAnimals: 4
}

Map function sẽ được gọi cho mỗi document, trả về giá tri emit("1995-12", 3) and emit("1995-12", 4). Sau đó reduce function sẽ được gọi reduce("1995-12", [3, 4]) và trả về 7.

The map and reduce function, giống như là một imperative languge, chúng nói cách thức data được xử lý (HOW). Và chúng phải là function thuần, nghĩa là chúng chỉ được sử dụng input data, và không thể thực hiện thêm câu query database nào khác để truy vấn thêm dữ liệu. Những ràng buộc này cho phép cơ sở dữ liệu có thể chạy các hàm ở bất kỳ đâu, theo bất kỳ thứ tự nào, và chạy lại chúng khi xảy ra lỗi.

Graph-Like Data Models

Nếu như ứng dụng của bạn hầu hết chỉ có one-to-many relationship (dạng cây) hoặc không có quan hệ giữa các record, document model là một lựa chọn tốt.

Nhưng nếu có quá nhiều mối quan hệ many-to-many, relational database có thể giúp bạn handle những trường hợp đơn giản. Nhưng nếu connection giữa các record trở lên phức tạp, graph data có thể là lựa chọn tiếp theo của bạn để model hoá data.

Một đồ thị gồm 2 objects: vertices - nút (nodes hoặc entities) và edges - cạnh (relationships). Có rất nhiều ví dụ về graph data model:

Social graphs: vertices là con người, nếu hai người bất kỳ biết nhau, sẽ có cạnh nối giữa họ
The web graph: vertices là những trang web, edges nếu có HTML link tới trang đó.

Lưu ý: Trong một đồ thị (graph), có thể tồn tại nhiều loại đỉnh (vertices) và cạnh (edges) khác nhau.
Ví dụ:

Vertices có thể là con người, địa điểm hoặc sự kiện.
Edges có thể biểu diễn mối quan hệ giữa hai người, hoặc hành động một người thực hiện check-in tại một địa điểm.

Trong phần này chúng ta sẽ sử dụng ví dụ sau để mô tả các dặc tính của graph-like model.

Một ví dụ về graph-structure data. Nó hiển thị thông tin về Lucy và Alain. Lucy from Idaho and Alain from Beaune, France. They are married and living in London.

Chúng ta có thể lưu thông tin của graph trên trong SQL bằng cách tạo 2 tables vertices và edges như sau:

CREATE TABLE vertices (
    vertex_id   INTEGER PRIMARY KEY,
    properties  JSON
);

CREATE TABLE edges (
    edge_id      INTEGER PRIMARY KEY,
    tail_vertex  INTEGER REFERENCES vertices (vertex_id),
    head_vertex  INTEGER REFERENCES vertices (vertex_id),
    label        TEXT,
    properties   JSON
);

CREATE INDEX edges_tails ON edges (tail_vertex);
CREATE INDEX edges_heads ON edges (head_vertex);

Bất cứ node nào (vertices) có thể tạo edges liên kết tới bất kỳ vertices nào, không có ràng buộc nào về các loại vertices có thể connect tới
Cho bất kỳ một vertex nào, chúng ta có thể dễ dàng tìm ra các edges đến và đi, đó là lý do vì sao phải có 2 một tail_vertex and head_vertex ở table edges trên
Bằng cách thêm các thuộc tính vào cột label và properties, chúng ta có thể dễ dàng thêm cái loại relationship khác nhau mà vẫn giữ được structure của graph.

Khi put data graph vô SQL, việc query có thể có gặp một vài khó khăn. Trong relation database, chúng ta đã biết sẵn table nào join với table nào. Nhưng trong graph data, chúng ta phải duyệt qua rất nhiều edges để biết được vertex nào để join. Trong ví dụ của chúng ta, một edge LIVES_IN của một người có thể trỏ đến nhiều loại địa điểm khác nhau: đường, thành phố, quận, vùng, bang, Ví dụ: Một thành phố có thể nằm trong một vùng, vùng đó lại nằm trong một bang, bang nằm trong một quốc gia, … Nói cách khác, cạnh LIVES_IN có thể trỏ trực tiếp đến đỉnh địa điểm mà bạn đang tìm, hoặc có thể cách vài cấp trong hệ thống phân cấp địa lý.

The Cypher Query Language

Cypher là một declarative query language, đùng để định nghĩa graph và sau đó có thể query trong đó. Được dùng trong Neo4j graph database.

Summary

Mô hình dữ liệu là một chủ đề rất rộng, và trong chương này chúng ta đã điểm qua nhanh một loạt các mô hình khác nhau. Chúng ta không có đủ không gian để đi sâu vào tất cả chi tiết của từng mô hình, nhưng hy vọng phần tổng quan này đã đủ để khơi gợi hứng thú, giúp bạn tìm hiểu thêm về mô hình nào phù hợp nhất với yêu cầu của ứng dụng của mình.

Hy vọng bài viết này đã mang đến cho bạn một vài góc nhìn mới về system design. Nếu có thắc mắc, đừng ngần ngại để lại bình luận – mình luôn sẵn sàng trao đổi thêm.

– mình sẽ rất trân trọng!

Xây dựng ứng dụng có tính tin cậy, khả năng mở rộng và có thể bảo trì

Quang — Mon, 15 Sep 2025 09:13:17 GMT

Bài viết này lược dịch từ chương 1 cuốn sách “Designing data sensitive applications” của Martin Kleppmann

Giới thiệu

Những ứng dụng ngày nay chủ yếu là “data-intensive”, nghĩa là sự giới hạn tính toán của CPU không phải là yếu tố cốt lõi của ứng dung. Những vấn đề lớn thường gặp phải là khối lượng data lớn (Volume), sự phức tạp của data (Variety) và tốc độ thay đổi (Velocity).

Có rất nhiều ví dụ về data-intensive application:

Database: để lưu trữ data, ứng dụng khác có thể truy vấn sau đó
Caches: Lưu trữ kết quả của các tính toán phức tạp, có thể sử dụng sau đó mà không cần tính toán lại
Search index: Cho phép users tìm kiếm theo keywords
….
Thanks for reading! This post is public so feel free to share it.
Share

Chúng ta thường sử dụng chúng như thế chúng là có sẵn như nước và không khí, điều đó là vì sự phức tạp của một data system đã được trừ trượng hoá (abstraction). Nhưng đằng sau bức màn thì không đơn giản như vậy. Có rất nhiều database systems với rất nhiều thuộc tính khác nhau và phuc vụ những yêu cầu khác nhau của những ứng dụng khác nhau. Có rất nhiều cách tiếp cận khác nhau có từng yêu cầu cụ thể. Khi xây dựng một ứng dụng, chúng ta phải tìm hiểu xem tools nào và cách tiếp cận nào là phù hợp. Khó khăn nảy sinh trong việc phối hợp các công cụ, vì không công cụ nào có thể tự xử lý toàn bộ.

Trong chương này, chúng ta sẽ tìm hiểu thế nào là một hệ thống dữ liệu tin cậy, có khả năng mở rộng và dễ bảo trì.

Data system là gì?

Chúng ta nghe nói về rất nhiều thứ: databases, queues, caches và được phân loại vào các loại công cụ khác nhau. Tại sao cần phải gom chúng vào một term chung “data system”?

Có rất nhiều tools mới trong những năm gần đây, và thường được optimized cho nhiều use case và không fit vào bất kì traditional categories. Ví dụ: Redis có thể là datastores hoặc message queues, Apache Kafka có thể là message queues hoặc database. Càng ngày, ranh giới giữa các khái niệm đó càng mờ.
Nhiều ứng dụng ngày này, một tool không thể đáp ứng được tất cả yêu cầu. Và thường được chia nhỏ thành từng task để có thể thực thi ở các tool khác nhau. Trong ví dụ sau, một ứng dụng có thể có application-managed caching( Mencached), full-text search server (such as Elasticsearch or Solr), main database, message queues

Figure 1-1. One possible architecture for a data system that combines several components.

Khi xây dựng một ứng dụng đòi hỏi sự kết hợp của rất nhiều tools chúng ta phải trả lời những câu hỏi sau: Làm thế nào để đảm bảo độ chính xác và nhất quán của data, kể cả trong trường hợp một số thứ bị lỗi. Làm thế nào để đảm bảo consistently good performance, kể cả khi một vài phần của system bị quá tải hay xuống cấp. Làm thế nào có thể tăng tải khi có nhu cầu? API như thế nào thì được xem là tốt cho dịch vụ?

Có ba vấn đề lớn khi phát triển hệ thống phần mềm ngày nay: Reliability, Scalability, Reliability.

Reliability (tính tin cậy)

Tính tin cậy của một hệ thống phần mềm là:

Thực hiện những yêu cầu như user mong muốn
Phần mềm vẫn hoạt động khi user sai sót hoặc có những hành động không lường trước.
Hiệu năng tốt với khối lượng tải và data dưới mức yêu cầu.
Hệ thống có thể ngăn chặn mọi truy cập trái phép và hành vi lạm dụng.

Tóm lại: Tính tin cậy là khả năng hệ thống vẫn làm việc chính xác ngay cả khi có một số thứ chạy không đúng.

Một số thử chạy không đúng được gọi là “faults”. Một hệ thống có khả năng như trên gọi là có khả năng chịu lỗi (fault-tolerant hoặc resilient).

Một số faults có thể xảy ra trong quá trình hệ thống phát triển và vận hành:

Hardware Faults

Ổ cứng bị đầy, RAM bị hỏng, cúp điện hay ai đó cắm nhầm cáp mạng, đó là những hardware faults phổ biến.

Software Errors

Lỗi phần mềm thường bao gồm:

A software bug make system crash
Một process sử dụng hết shared resource: CPU, memory, disk space…
Một service từ bên thứ ba bị chậm, dẫn đến hệ thống bị treo
Một lỗi nhỏ ảnh hưởng tới một module khác, làm module đó lỗi làm thành một lỗi lớn hơn.

Human Errors

System data được thiết kế, phát triển và bảo trì bởi con người mà con người thì rất hay mắc sai lầm.

Scalability (Có khả năng mở rộng)

Cho dù một system có thể hoạt động tốt hôm nay, có thể nó sẽ không hoạt động tốt trong tương lại. Lý do thường là vì hệ phải phải chịu thêm tải: Có thể system phát triển từ 100K users lên tới 1M users hoặc từ 1M lên 10M. Thường là số lượng data cần xử lý tằng lên (Volume). Tính có khả năng mở rộng trả lời cho câu hỏi: “Nếu hệ thống phát triển theo một cách nào đó, chúng ta có những lựa chọn nào để tăng khả năng xử lý data của hệ thống” hay “Làm thế nào để thêm tài nguyên để xử lý lượng data tăng thêm”.

Đầu tiên, chúng ta cần phải định lượng được tải của hệ thống, sau đó mô tả bằng một vài con số, gọi là load parameters. Một vài parameters phổ biến như: số lượng request mỗi giây, tỉ lệ giữa đọc và ghi database, số lượng user active cùng một lúc ở một chatroom. Ví dụ load parameter của X(twister) vào năm 2012

Post tweet: Một user có thể xuất bản một message tới những người followers( trung bình: 4.6k requests/sec, cao điểm: 12k requests/sec.
Home timeline: Một user có thể xem các tweets của những người mà họ follow (300k request/sec

Describing Performance

Để mô tả performance của hệ thống, chúng ta thường có 2 cách tiếp cận:

Nếu load parameters tăng và resource giữ nguyên ( CPU, RAM ..) thì performance của hệ thống ảnh hưởng thế nào
Nếu load parameters tằng và performance không thay đổi thì phải thay đổi resource như thế nào?

Ví dụ, một hệ thống batch process (Haddop) chúng ta thường quan tầm tới throughput - số lượng record có thể xử lý trong một giây. Trong web application, response time - thời gian từ khi user send request tới lúc nhận được response, là giá trị mà ta thường quan tâm. Một lưu ý về response time là nó thường không phải là một số cố định, mà là một phân phối của các giá trị.

Approaches for Coping with Load

Chúng ta sẽ thảo luận tiếp, làm thế nào để giữ cho performance vẫn tốt khi load parameters tăng. Một kiến trúc phù hợp với một mức tải nhất định thường sẽ khó có thể xử lý được khi tải tăng gấp 10 lần. Vì vậy, nếu bạn đang làm việc trên một dịch vụ có tốc độ tăng trưởng nhanh, rất có thể bạn sẽ phải suy nghĩ lại về kiến trúc mỗi khi tải tăng theo bậc số mười — hoặc thậm chí còn thường xuyên hơn thế.

Có hai cách tiếp cận: scaling up (mở rộng theo chiều dọc, tức nâng cấp sang một máy tính mạnh hơn) và scaling out (mở rộng theo chiều ngang, phân phối tải sang nhiều máy tính). Việc phân phối tải thường được gọi là kiến trúc shared-nothing. Do chi phí của các siêu máy tính thường rất cao, nên scaling out thường là lựa chọn khó tránh. Tuy nhiên, trên thực tế có thể kết hợp cả hai phương pháp: đôi khi sử dụng một vài máy mạnh vẫn đơn giản và rẻ hơn so với việc triển khai trên nhiều máy ảo nhỏ.

Việc chuyển đổi từ stateful data system trên một node đơn lẻ sang distributing stateless service thường mang đến rất nhiều sự phức tạp mới. Vì vậy thường thì mọi người sẽ scale up cho tới khi qua đắt đỏ và chuyển sang scale out.

Thiết kế hệ thống phụ thuộc trức tiếp vào nhu cầu củ ứng dụng. Không có một design nào one-size-fits-all. Một hệ thống thiết kế để handle 100,000 request per second và mỗi request 1kB size, sẽ rất khác một hệ thông handle 1 request per second và mỗi request 1GB size. Nhưng các bạn đừng vội lo lắng, các hệ thống được xây dựng từ các general-purpose building blocks và mỗi blocks này thường có pattern giống nhau. Và chúng ta sẽ lần lượt tìm hiểu về chúng.

Maintainability (Có thể bảo trì)

Chi phí phát triển phần mềm thường nhỏ hơn chi phí bảo trì - fix bugs, chi phí giữ cho hệ thống hoạt động, điều tra lỗi, thêm feature mới ….

Và thật không may, rất nhiều người không thích làm công việc maintenance legacy system. Sửa những lỗi của người khác, làm việc với những platforms đã lỗi thời, hay thêm những tính năng mới mà hệ thống cũ chưa bao giờ có kế hoạch thực hiện. Mỗi legacy system đều có những điểm khó chịu riêng, vì vậy rất khó để đưa ra những khuyến nghị chung trong việc xử lý chúng.

Do đó, khi thiết kế hệ thống, chúng ta nên hướng tới việc giảm thiểu tối đa “gánh nặng” cho những người sẽ bảo trì về sau. Ba nguyên tắc thiết kế quan trọng có thể hỗ trợ là:

Operability: Giúp hệ thống dễ dàng vận hành.
Simplicity: Giữ cho hệ thống đơn giản, loại bỏ tối đa sự phức tạp để các kỹ sư mới có thể dễ dàng tiếp cận.
Evolvability: Đảm bảo hệ thống có thể linh hoạt thay đổi, đáp ứng tốt các yêu cầu trong tương lai.

Khác với Reliability và Scalability, không có một công thức đơn giản nào để đạt được cả ba yếu tố trên. Thay vào đó, khi thiết kế hệ thống, chúng ta cần luôn đặt operability, simplicity và evolvability trong tâm trí.

Kết luận

Khi xây dựng hệ thống dữ liệu, ba yếu tố cốt lõi cần hướng tới là Reliability (độ tin cậy), Scalability (khả năng mở rộng) và Maintainability (khả năng bảo trì). Để đạt được điều này, kiến trúc cần được thiết kế linh hoạt, kết hợp các công cụ phù hợp, và đặc biệt chú trọng đến operability, simplicity và evolvability để hệ thống có thể vận hành ổn định, phát triển bền vững và thích ứng với tương lai.

Hi vọng bài viết này giúp bạn học thêm được một vài điều mới mẻ về system design. Nếu có câu hỏi gì đừng ngần ngại để lại comment. Nếu bạn thấy bài viết hữu ích, hãy subscribe để nhận thêm những bài viết chuyên sâu về kiến trúc hệ thống và microservices.

Tại sao các database engine lại yêu thích B-Tree?

Quang — Wed, 10 Sep 2025 07:52:50 GMT

Source: https://carlpaton.github.io/2021/06/rosetta-code-invert-a-binary-tree/. Caí meme này có vẻ không liên quan tới B-Tree nhưng có vẻ đúng đúng đúng với tình trạng phỏng vấn hiện nay :D

Lược dịch từ: https://planetscale.com/blog/btrees-and-database-indexes#what-is-a-b-tree

Buy Me a Coffee

Giới thiệu

Trong các loại cấu trúc dữ liệu chúng ta đã được học ở lớp cấu trúc dữ liệu và giải thuật, có lẽ B-Tree là hay được nhắc tới nhất. Nó đóng vài trong quan trọng trong việc thiết kế indexes trong các database engine phổ biến như MySQL, PostgresSQL. Trong bài viết này hãy cũng nhau tìm hiểu cách B-Tree hoạt động và cách áp dụng nó vào bài toán indexing trong database system.

B-Tree chứa data thành từng cặp “keys-values”, “tree” ở giống như là một root system với nhiều thành phần con như trong một hệ thông folder system. Đây là hình ảnh mô tả một B-tree.

B-Tree được tạo thành từ các node ( hình chữ nhật) và các pointer trỏ tới các node con ( hình mũi tên). Node trên cùng là root node, các node ở dòng cuối là leaf node (node lá), và mọi node khác là node trung gian. Ví dụ sau là một B-Tree có tối đa 2 keys trong một node

Một cây B-tree bậc K là một cấu trúc cây cân bằng với các đặc điểm sau:

Mỗi nút có thể chứa tối đa K cặp khóa/giá trị, với số lượng cặp N thỏa mãn 1
Mỗi nút trong (không phải lá, không phải gốc) chứa ít nhất ⌈N/2⌉ cặp khóa/giá trị.
Một nút có N cặp khóa/giá trị thì sẽ có đúng N+1 nút con.
Nút gốc phải có ít nhất một khóa và hai nút con, trừ khi nó là nút duy nhất trong cây.
Share
Tất cả các nút lá đều nằm trên cùng một mức, đảm bảo cây luôn cân bằng.

Một đặc điểm khác của B-Tree là tính có thứ tự. Mỗi node được giữ theo một thứ tự, bất kỳ node con bên trái sẽ có key nhỏ hơn các node bên phải. Mục đính của việc giữ thứ tự là để việc search hiệu quả hơn. Khi muốn tìm một giá trị, bắt đầu từ root node:

Kiểm tra node có chứa key đang tìm
Follow child pointer xuống phía node con và lặp lại quá trinhf trên

Ví dụ như sau:

Việc đọc và ghi dữ liệu trên ổ đĩa được thực hiện theo các đơn vị gọi là block. Mỗi block có kích thước cố định, thường là 4096, 8192 hoặc 16384 byte (tương ứng 4KB, 8KB, 16KB). Một ổ đĩa có thể chứa đến hàng triệu, thậm chí hàng tỷ block.
Trong khi đó, RAM hoạt động theo một cơ chế khác: nó truy xuất dữ liệu ở mức từng byte (per-byte level).

B-Tree rất thích hợp khi làm việc với lượng data lớn cần được lưu xuống ổ cứng. B-Tree có thể làm được điều này vị mỗi node chứa số lượng byte nhất định, thường bằng với disk block ( hoặc bằng số nguyên lần disk block).

The B+Tree

Subscribe now

Một cải tiến của B-Tree là B+Tree, nó tương tự như B-Tree nhưng có một số thay đổi

Key/value chỉ được chứa ở node lá
Non-leaf node chỉ chưa key và pointers tới child nodes.

Trong MySQL còn có thêm 2 rules nữa:

Non-leaf node chứa N child pointers thay vì N + 1
Tất các các node chứa thêm 2 pointer “next” và “previous”, điều này cho phép di chuyển trên cùng một level mà không cần quay lại node trên, cho phép mỗi level giống như một doubly-linked list.

Nhưng tại sao B+Tree lại tốt cho database, có 2 lý do chính như sau:

Những node trung gian không chứa values, nên có thể thêm nhiều key vào mỗi node. Việc có nhiều keys ở mỗi node giúp cây ngắn hơn, tốn ít thời gian hơn để tìm kiếm
Tất cả values đều được chứa ở cùng một level, và di chuyển ở bottom-level

Một câu hỏi dành cho độc giả: Vậy tại sao chúng ta không dùng một mảng có thứ tự (ordered array hoặc order link-list) để lưu trữ index thay cho cấu trúc B+Tree phức tạp?

B+trees in MySQL

Trong MySQL, engine “InnoDB” chủ yếu sử dụng B+Tree để lưu tất cả table data và primary key thường được dùng làm key.

Bạn phải chỉ định một khoá chính (primary key) khi tạo một InnoDB tables, thông thường chúng ta tạo một auto-incrementing integer cho giá trị này. Sau đó, MySQL + InnoDB sẽ tạo một B+Tree cho mỗi table được tạo, key là primary key và values là những gía trị còn lại của các cột trong mỗi dòng.

Source: https://planetscale.com/blog/btrees-and-database-indexes#the-btree

Kích thước mặc định của mỗi node là 16KB. Khi cần truy xuất, MySQL sẽ nạp toàn bộ dữ liệu của node đó (bao gồm cả keys, values, …). Việc này xảy ra ngay cả khi chỉ một phần nhỏ dữ liệu được sử dụng, bởi vì toàn bộ node được lưu trữ trong cùng một block trên disk. Và số lượng dòng cho mỗi node phụ thuộc vào việc mỗi dòng “lớn” thế nào. Nếu table đó chỉ chứa vài cột, một node có thể chứa tới hàng trăm dòng. Trong một table lớn ( table với rất nhiều cột), mỗi node lá chỉ có thế chứa vài dòng. InnoDB có thể support việc dung lượng một row lớn hơn một block, chúng ta sẽ tìm hiểu cách thức làm việc ở một bài khác.

Thông thường, mỗi table thường có thêm một loại index nữa (secondary indexes) ngoài indexs tạo bởi primary key. Secondary indexes thường được sử dụng để tăng tốc câu query trong Where clause. Một cây B+Tree mới được tạo với key là giá trị của (những) column được user lựa chọn để đánh index và values là primary key của dòng tương ứng. Khi một câu query có sử dụng column được đánh secondary index:

Search sẽ được thực hiện ở secondary index B+tree.
Primary keys match sẽ được collect lại
Những primary keys này sẽ được dùng để lookup trên main B+tree index để lấy row data.

Tổng quan, chúng ta luôn muốn số lương block/nodes cần phải visit trong mỗi câu query là nhỏ nhất. Càng ít node cần visit, câu query càng chạy nhanh. Primary key is key factor cho việc giảm số lượng node cần visit. Do đó việc chọn primary key sẽ ảnh hưởng tới layout của disk chứa data trong table.

Page and InnoDB

Subscribe now

Trong InnoDB, các node của B+tree thường có kích thước 16KB, tương ứng với kích thước của một InnoDB page. Khi thực hiện một truy vấn (và phải duyệt qua các B+tree), InnoDB không đọc riêng lẻ từng hàng hay từng cột từ ổ đĩa. Thay vào đó, mỗi khi cần truy xuất một phần dữ liệu, nó sẽ nạp toàn bộ page liên quan từ disk vào bộ nhớ.

InnoDB có một vài tricks để tăng tốc quá trình này, một trong số chúng là buffer pool. Buffer pool là một in-memory cache, đứng giữa MySQL và disk. Khi MySQL cần đọc một page, đầu tiên nó sẽ kiểm tra xem page đó có trong buffer pool hay chưa. Nếu có nó sẽ đọc từ đó và bỏ qua việc đọc trên disk (I/O operation). Nếu không, nó tìm page đó on-disk và add vào buffer pool.

Kết luận

Trong bài viết này chúng ta đã tìm hiểu về B-Tree và B+Tree, indexes trong MySQL. Có một vài trang web mô phỏng các B-Tree và B+Tree hoạt động, bạn đọc có thể tham khảo tại https://bplustree.app/ hoặc https://btree.app/. Hi vọng bài viết này giúp bạn học thêm được một vài điều mới mẻ về database. Nếu có câu hỏi gì đừng ngần ngại để lại comment.

CQRS pattern trong mô hình microservices

Quang — Wed, 03 Sep 2025 13:52:40 GMT

Mở đầu

Command Query Responsibility Segregation (CQRS) là một mô hình thiết kế trong đó việc ghi dữ liệu và đọc dữ liệu từ database được tách thành hai mô hình riêng biệt. Cách tiếp cận này giúp hệ thống dễ dàng mở rộng, tối ưu hiệu năng và nâng cao khả năng bảo trì. Hãy cùng khám phá chi tiết về CQRS trong bài viết này.

Trong mô hình truyền thống, một data model sẽ đảm nhận cả hai việc đọc và ghi. Hướng tiếp cận này rất phù hợp với cái hành động cơ bản: create, read, update và delete (CRUD).

Khi ứng dụng phát triển, việc tối ưu đồng thời các thao tác đọc và ghi trên cùng một mô hình dữ liệu trở nên ngày càng khó khăn. Các thao tác đọc và ghi thường có yêu cầu khác nhau về hiệu năng và khả năng mở rộng. Kiến trúc CRUD truyền thống không tính đến sự bất cân xứng này, dẫn đến một số thách thức sau:

Thanks for reading! This post is public so feel free to share it.

Data mismatch
Lock contention
Performance problem
Security challenges

Giải pháp

Sư dụng mô hình CQRS để tách biệt việc ghi ( commands) và đọc ( queries). Command update data, queries retrieve data. CQRS rất hiệu quả trong bài toán tách biệt giữa việc đọc và ghi.

Commands: Đại diện cho một business task thay vì low-level data updates. Phương pháp này giúp dễ dàng nắm bắt ý định của user và điều chỉnh các commands phù hợp với qui trình kinh doanh.
Queries: Không bao giờ thay đổi data, nó chỉ chuyển đổi data theo format thuận tiện nào đó mà không chứa bất kì nghiệp vụ nào.
Thanks for reading! Subscribe for free to receive new posts and support my work.

Có hai phương pháp triển khai CQRS, mỗi phương pháp có ưu nhược điểm riêng.

Separate models in a single data store

Đây là một cách tiếp cận cơ bản của CQSR, cả việc đọc và ghi đều dùng chung một database, nhưng được logic đọc và ghi được tách riêng biệt. Phương pháp này cải thiện clarity, performance, and scalability bằng cách tách từng model handle riêng biệt

Write model: thiết kế cho commands update và persist dữ liệu. Nó bao gồm cả việc validate data và domain logic. Đảm bảo data consistency bằng cách optimizing for transactional integrity và business processes.
Read model: được thiết kế để queries. Tập trung vào việc tạo ra các DTO hoặc projections data.

Ví dụ minh hoạ:

# ---------------------------------------------
# CQRS Demo: Separate Models, Single Data Store
# ---------------------------------------------

# Single data store (dictionary)
data_store = {
    "products": {}  # product_id -> {"name": ..., "price": ...}
}

# -----------------------
# Write Model (Commands)
# -----------------------
class ProductWriteModel:
    def add_product(self, product_id, name, price):
        data_store["products"][product_id] = {"name": name, "price": price}
        print(f"Product added: {name} - ${price}")

    def update_price(self, product_id, new_price):
        if product_id in data_store["products"]:
            data_store["products"][product_id]["price"] = new_price
            print(f"Price updated for {data_store['products'][product_id]['name']} to ${new_price}")
        else:
            print("Product not found!")

# -----------------------
# Read Model (Queries)
# -----------------------
class ProductReadModel:
    def list_products(self):
        print("\nAvailable products:")
        for pid, info in data_store["products"].items():
            print(f"{pid}: {info['name']} - ${info['price']}")

    def get_product(self, product_id):
        return data_store["products"].get(product_id, "Product not found")

# -----------------------
# Demo
# -----------------------
if __name__ == "__main__":
    # Command side
    write_model = ProductWriteModel()
    write_model.add_product(1, "Laptop", 1200)
    write_model.add_product(2, "Phone", 800)
    write_model.update_price(2, 750)

    # Query side
    read_model = ProductReadModel()
    read_model.list_products()
    print("\nGet single product:", read_model.get_product(2))

Cả hai mô hình đều sử dụng một kho dữ liệu duy nhất, nhưng trách nhiệm được tách riêng:
- ProductWriteModel → xử lý tất cả thao tác ghi (write/command)
- ProductReadModel → xử lý tất cả thao tác đọc (read/query)
Mô hình đọc không chứa logic nghiệp vụ, chỉ truy xuất trạng thái hiện tại của dữ liệu.
Thiết lập này mô phỏng cách CQRS trên một cơ sở dữ liệu duy nhất, mà không cần tạo kho lưu trữ riêng biệt.

Separate models in different data stores

Đây là cách tiếp cận nâng cao hơn, việc tách biết ra hai models giúp việc. scale each model dễ dàng hơn và phù hợp với nhu cầu hơn. Và có thể sử dụng các database khác nhau cho từng model. Ví dụ document database cho việc đọc và relational data cho ghi dữ liệu.

Một vấn đề khi tách database riêng biệt là phải đảm bảo data được đồng bộ hoá (synchronized). Một cách đơn là là áp dụng kỹ thuật CDC, mình đã có một vài về chủ đề này, cách bạn có thể đọc lại tại hai bài viết sau đây, hoặc có thể sử dụng kiến trúc event-driven.

Ví dụ:

# ---------------------------------------------
# CQRS Demo: Separate Models, Different Data Stores
# ---------------------------------------------

# Write data store (Command)
write_store = {}  # product_id -> {"name": ..., "price": ...}

# Read data store (Query) - could be optimized for reads
read_store = {}   # product_id -> {"name": ..., "price": ..., "display_price": ...}

# -----------------------
# Write Model (Commands)
# -----------------------
class ProductWriteModel:
    def add_product(self, product_id, name, price):
        write_store[product_id] = {"name": name, "price": price}
        # Update the read store as well
        read_store[product_id] = {"name": name, "display_price": f"${price}"}
        print(f"Product added: {name} - ${price}")

    def update_price(self, product_id, new_price):
        if product_id in write_store:
            write_store[product_id]["price"] = new_price
            # Update read store for queries
            read_store[product_id]["display_price"] = f"${new_price}"
            print(f"Price updated for {write_store[product_id]['name']} to ${new_price}")
        else:
            print("Product not found!")

# -----------------------
# Read Model (Queries)
# -----------------------
class ProductReadModel:
    def list_products(self):
        print("\nAvailable products (read model):")
        for pid, info in read_store.items():
            print(f"{pid}: {info['name']} - {info['display_price']}")

    def get_product(self, product_id):
        return read_store.get(product_id, "Product not found")

# -----------------------
# Demo
# -----------------------
if __name__ == "__main__":
    # Command side
    write_model = ProductWriteModel()
    write_model.add_product(1, "Laptop", 1200)
    write_model.add_product(2, "Phone", 800)
    write_model.update_price(2, 750)

    # Query side
    read_model = ProductReadModel()
    read_model.list_products()
    print("\nGet single product:", read_model.get_product(2))

Trong ví dụ trên:

write_store chỉ phục vụ ghi dữ liệu, read_store phục vụ truy vấn.
Read model có thể được tối ưu hóa cho truy vấn (ví dụ: định dạng hiển thị, summary view).
Mỗi kho dữ liệu có thể được lưu trữ trên cơ sở dữ liệu khác nhau, phục vụ hiệu năng và khả năng mở rộng.

Kết luận

CQRS là một mô hình thiết kế mạnh mẽ giúp tách biệt trách nhiệm giữa đọc và ghi dữ liệu, từ đó tối ưu hiệu năng, khả năng mở rộng và dễ bảo trì hệ thống hơn. Bằng cách áp dụng CQRS, bạn có thể xây dựng các ứng dụng linh hoạt, dễ quản lý và mở rộng theo nhu cầu thực tế.

Nếu bạn thấy bài viết hữu ích, hãy nhấn subscribe để nhận các bài viết tiếp theo về kiến trúc hệ thống và thiết kế phần mềm.

Thanks for reading! This post is public so feel free to share it.

Nếu bạn có bất kỳ thắc mắc hoặc muốn thảo luận thêm, hãy để lại comment bên dưới — mình sẽ phản hồi sớm nhất có thể!

Đọc thêm:

https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs
https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven

AsyncIO nâng cao trong Python: Task, Future, Queue, Lock, Semaphore

Quang — Fri, 22 Aug 2025 07:00:06 GMT

Trong bài viết trước, chúng ta đã tìm hiểu về lập trình bất đồng bộ trong Python, thư viện asyncio và một số ví dụ cơ bản (bạn có thể xem lại tại đây).

Tiếp nối nội dung đó, bài này sẽ đi sâu vào các khái niệm nâng cao gồm: Task, Future, Queue, Lock và Semaphore. Việc nắm vững những khái niệm này sẽ giúp bạn chủ động và tự tin hơn khi làm việc với asyncio.

Coroutines, Task và Future

Đầu tiên, hãy cũng nhau tìm hiểu lại khái niệm coroutines. Ví dụ dưới đây khai báo một coroutine object bằng các sử dụng cú pháp async/await

import asyncio

async def main():
    print('hello')
    await asyncio.sleep(1)
    print('world')

asyncio.run(main())
hello
word

Nếu chỉ đơn giản gọi hàm main, một coroutine sẽ không được thực thi

main()

Để chạy một coroutine, asyncio cung cấp một vài cách sau:

Thanks for reading! This post is public so feel free to share it.

Dùng asyncio.run như ví dụ trên

Awaiting một coroutine. Ví dụ sau sử dung awaiting. Để ý chúng ta sẽ tốn 3 giây vì 2 coroutine này chạy lần lượt, hoàn tất mới xong cái tiếp theo

import asyncio
import time

async def say_after(delay, what):
    await asyncio.sleep(delay)
    print(what)

async def main():
    print(f"started at {time.strftime('%X')}")

    await say_after(1, 'hello')
    await say_after(2, 'world')

    print(f"finished at {time.strftime('%X')}")

asyncio.run(main())

## Output:

started at 17:13:52
hello
world
finished at 17:13:55

asyncio.create_task: dùng để chạy các coroutine concurrently. Chúng ta sẽ modify lại ví dụ trên bằng các chạy 2 coroutine say_after concurrently. Chúng ta chú ý, output ở ví dụ này chỉ tốn khoảng 2 giây, thay vì 3 giây như ví dụ trên, vì 2 task chạy concurrently.

async def main():
    task1 = asyncio.create_task(
        say_after(1, 'hello'))

    task2 = asyncio.create_task(
        say_after(2, 'world'))

    print(f"started at {time.strftime('%X')}")

    # Wait until both tasks are completed (should take
    # around 2 seconds.)
    await task1
    await task2

    print(f"finished at {time.strftime('%X')}")


Output:
started at 17:14:32
hello
world
finished at 17:14:34

asyncio.TaskGroup, đây là cách hiện đại hơn thay thế create_task(). Output sẽ tương tự như ví dụ ở create_task

async def main():
    async with asyncio.TaskGroup() as tg:
        task1 = tg.create_task(
            say_after(1, 'hello'))

        task2 = tg.create_task(
            say_after(2, 'world'))

        print(f"started at {time.strftime('%X')}")

    # The await is implicit when the context manager exits.

    print(f"finished at {time.strftime('%X')}")

Awaitables

Một object trong Python được gọi là awaitable nếu nó được sử dụng trong “await” expression. Có ba loại object awaitable chính: coroutines, Task and Futures.

Coroutins và Task chúng ta đã tìm hiểu ở phần trước. Còn Futures là trường hợp đặc biết, một low-level awaitable objects đại diện cho một eventual result of an asynchronous operation.

Khi một Future được await, nghĩa là coroutine sẽ tạm dừng và chờ cho đến khi Future đó được xử lý (resolve) ở một nơi khác. Trong asyncio, Future được dùng để kết nối giữa cơ chế callback truyền thống và cú pháp async/await. Thông thường, lập trình viên ứng dụng không cần phải tự tạo Future. Tuy nhiên, một số thư viện hoặc API của asyncio có thể trả về Future, và những đối tượng này hoàn toàn có thể được await.

Synchronization Primitives

Synchronization Primitives - các công cụ đồng bộ trong asyncio là những cơ chế giúp nhiều coroutine chia sẻ tài nguyên chung một các an toàn, tránh tính trạng race condition hoặc deadlock. Những cơ chế, công cụ này giống như trong threading module nhưng cần chú ý một số điểm:

asyncio primitives are not thread-safe, nếu muốn thread-safe thì dùng (https://docs.python.org/3/library/threading.html#module-threading)
Không có tham số timeout trong các synchronization primitives, nếu cần timeout thì sử dụng asyncio.wait_for() function.

Cùng tìm hiểu các công cụ cơ bản: Lock, Event, Condition, Semaphore/BoundedSemaphore và Barrier

Lock

Chi cho phép một coroutine truy cập vào shared resource. Chú ý không thread-safe.

lock = asyncio.Lock()
async with lock:
    # code an toàn

Event

Dùng để notify nhiều asyncio task khi có một sự kiện xảy ra. Hoạt động như một flag có 2 trạng thái:

Chưa được set (False) → các coroutine nào await event.wait() sẽ bị chặn

Được set (True) → tất cả coroutine đang chờ sẽ tiếp tục chạy ngay lập tức.

import asyncio

async def waiter(event, name):
    print(f"{name} is waiting for the event...")
    await event.wait()  # chờ cho đến khi event được set
    print(f"{name} received the event!")

async def main():
    event = asyncio.Event()

    # 3 coroutine đang chờ tín hiệu
    tasks = [asyncio.create_task(waiter(event, f"Task{i}")) for i in range(3)]

    print("Main: sleeping for 2 seconds before setting event")
    await asyncio.sleep(2)

    print("Main: setting the event")
    event.set()  # phát tín hiệu → tất cả Task0,1,2 chạy tiếp

    await asyncio.gather(*tasks)
asyncio.run(main())

#### Output:

Task0 is waiting for the event...
Task1 is waiting for the event...
Task2 is waiting for the event...
Main: sleeping for 2 seconds before setting event
Main: setting the event
Task0 received the event!
Task1 received the event!
Task2 received the event!

Condition

Cao cấp hơn Event, cho phép nhiều coroutine chờ trên cùng một điều kiện và được thông báo khi điều kiện thay đổi.

Semaphore/BoundedSemaphore

Giới hạn số coroutine được phép truy cập vào tài nguyên cùng lúc (thay vì chỉ 1 như Lock).

Ví dụ: Giới hạn 3 kết nối DB đồng thời.

sem = asyncio.Semaphore(3)
async with sem:
    # tối đa 3 coroutine vào cùng lúc

Barrier

Đồng bộ nhiều coroutine, bắt buộc chúng chờ đủ số lượng trước khi cùng tiến tiếp.

Áp dụng: Web Crawler Bất Đồng Bộ

Hãy cùng nhau xem cách sử dụng các công cụ trên trong một ví dụ cụ thể. Ví dụ chúng ta đang xây dựng web crawler tải nhiều URL vì vậy có thể tận dụng asyncio primitives như sau:

Queue: quản lý danh sách URL (Producer–Consumer).
Lock: đảm bảo ghi log không bị rối.
Semaphore: giới hạn số request đồng thời (tránh bị block).
Event: báo hiệu dừng khi hết URL hoặc người dùng ngắt crawler.

import asyncio
import aiohttp

async def fetch(session, url, sem, lock):
    async with sem:  # Semaphore: giới hạn số request đồng thời
        async with session.get(url) as resp:
            data = await resp.text()
            async with lock:  # Lock: đảm bảo ghi log an toàn
                print(f"Fetched {url} with {len(data)} chars")
            return data

async def worker(name, queue, session, sem, lock, stop_event):
    while not stop_event.is_set():
        try:
            url = await asyncio.wait_for(queue.get(), timeout=2.0)
        except asyncio.TimeoutError:
            # Nếu queue trống lâu quá → có thể dừng
            stop_event.set()
            break
        await fetch(session, url, sem, lock)
        queue.task_done()

async def main():
    urls = [
        "https://example.com",
        "https://httpbin.org/get",
        "https://python.org",
        # thêm nhiều url khác...
    ]

    queue = asyncio.Queue()
    for url in urls:
        await queue.put(url)

    sem = asyncio.Semaphore(5)  # Tối đa 5 request đồng thời
    lock = asyncio.Lock()
    stop_event = asyncio.Event()

    async with aiohttp.ClientSession() as session:
        tasks = [
            asyncio.create_task(worker(f"worker-{i}", queue, session, sem, lock, stop_event))
            for i in range(3)
        ]
        await queue.join()   # Chờ đến khi tất cả url được xử lý
        stop_event.set()     # Báo hiệu dừng
        await asyncio.gather(*tasks)

asyncio.run(main())

Kết luận

Trong lập trình bất đồng bộ với Python, việc phối hợp nhiều coroutine cùng chạy là một thách thức lớn. Đó là lý do tại sao asyncio cung cấp các synchronization primitives như Event, Lock, Semaphore, và đặc biệt là Queue.

Event giúp phát tín hiệu giữa các coroutine.
Lock đảm bảo tài nguyên chỉ được một coroutine truy cập tại một thời điểm.
Semaphore mở rộng cơ chế Lock để giới hạn số coroutine được phép truy cập đồng thời.
Queue đóng vai trò như “đường ống dữ liệu” an toàn và tiện lợi trong mô hình Producer – Consumer.

Hiểu và sử dụng thành thạo những công cụ này sẽ giúp bạn:

Tránh race condition và deadlock.
Xây dựng pipeline xử lý dữ liệu bất đồng bộ.
Viết ứng dụng ổn định, dễ bảo trì, và có khả năng mở rộng.

Đọc thêm

https://docs.python.org/3/library/asyncio-sync.html
https://docs.python.org/3/library/asyncio-queue.html

Nếu bạn thấy bài viết hữu ích, hãy subscribe để nhận thêm những bài viết chuyên sâu về kiến trúc hệ thống và microservices.
Đừng ngần ngại để lại câu hỏi hoặc chia sẻ trải nghiệm của bạn với asyncio trong Python trong phần bình luận

Revoke JWT – Làm thế nào để thu hồi token chưa hết hạn?

Quang — Fri, 22 Aug 2025 03:07:19 GMT

Mở đầu

Trong bài trước chúng ta đã tìm hiểu về cách JWT hoạt động và các tích hợp JWT với OAuth 2.0. Bạn đọc có thể đọc lại tại đây:

JWT có một đặc điểm thú vị là nó không giữ trạng thái (stateless). Đây vừa là điểm mạnh, vừa là điểm yếu. Điểm mạnh là các service chỉ cần cầm token là có thể kiểm tra hợp lệ ngay, không cần gọi thêm database hay chia sẻ session phức tạp. Nhưng điểm yếu là… nếu muốn thu hồi token trước khi nó tự hết hạn thì lại khá đau đầu.

Thử tưởng tượng vài tình huống quen thuộc: người dùng nhấn logout, vừa đổi mật khẩu, hoặc xui hơn là tài khoản bị hack, thậm chí khóa bí mật để ký JWT bị lộ. Trong những trường hợp này, JWT không hề có cơ chế “revoke” sẵn cho chúng ta.

Trong bài viết này, mình sẽ chia sẻ một số cách phổ biến để giải quyết vấn đề này, kèm theo ưu và nhược điểm của từng cách để bạn dễ chọn cho hệ thống của mình.

Thanks for reading! This post is public so feel free to share it.

Tại sao JWT khó thu hồi trước khi hết hạn?

JWT được tạo ra bằng cách đóng gói thông tin vào phần payload, rồi ký lại bằng một secret key để đảm bảo tính toàn vẹn, không bị chỉnh sửa. Khi có một request gửi lên, service chỉ cần giải mã token, đọc nội dung payload và so sánh với chữ ký để biết token đó có hợp lệ hay không.

Trong payload có một trường rất quan trọng là exp – thời điểm token hết hạn. Vấn đề nằm ở chỗ: một khi token đã được phát hành, giá trị exp này cố định và không thể thay đổi. Điều đó đồng nghĩa với việc, trừ khi token tự hết hạn, còn nếu muốn “ngắt” nó sớm hơn (ví dụ khi user logout hoặc đổi mật khẩu), thì JWT mặc định không có cách nào hỗ trợ sẵn.

Các phương pháp phổ biến

Thiết lập thời gian hết hạn ngắn

Để tránh việc bắt người dùng đăng nhập lại liên tục, hầu hết hệ thống sẽ phát hành hai loại token khi user đăng nhập:

Access token: dùng để xác thực người dùng trong các request.
Refresh token: dùng để xin một access token mới khi access token đã hết hạn.

Một cách đơn giản và phổ biến để xử lý việc “thu hồi token” là:

Cho access token có thời gian sống ngắn.
Lưu danh sách các refresh token bị thu hồi (blacklist) trong cache, ví dụ Redis.
Khi client gửi request đổi refresh token lấy access token mới, server sẽ kiểm tra trong Redis xem refresh token đó có nằm trong blacklist không. Nếu không có, thì phát hành access token mới.

Ưu điểm

Hạn chế việc phải truy cập database phức tạp.
Việc kiểm tra trong Redis rất nhanh.

Nhược điểm

Access token vẫn còn hiệu lực cho đến khi hết hạn, ngay cả khi refresh token đã bị revoke.
Có thể giảm rủi ro bằng cách rút ngắn thời gian sống (exp) của access token, nhưng điều này đồng nghĩa với việc client sẽ phải xin token mới thường xuyên hơn → tăng số lần gọi đến server.

Ví dụ 1 middleware FastAPI

\n \n

\n\n \n

\n\n \n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

	from fastapi import FastAPI, Request, HTTPException, Depends
	from fastapi.responses import JSONResponse
	import jwt
	import time
	import aioredis
	\n
	# Secret và cấu hình token
	ACCESS_SECRET_KEY = "mysecret"
	REFRESH_SECRET_KEY = "refreshsecret"
	ALGORITHM = "HS256"
	ACCESS_TOKEN_EXPIRE_SECONDS = 60
	\n
	app = FastAPI()
	\n
	# Kết nối Redis
	@app.on_event("startup")
	async def startup_event():
	app.state.redis = await aioredis.from_url("redis://localhost")
	\n
	@app.on_event("shutdown")
	async def shutdown_event():
	await app.state.redis.close()
	\n
	\n
	# Middleware kiểm tra access token
	@app.middleware("http")
	async def jwt_middleware(request: Request, call_next):
	if request.url.path.startswith("/protected"):
	auth_header = request.headers.get("Authorization")
	if not auth_header or not auth_header.startswith("Bearer "):
	raise HTTPException(status_code=401, detail="Missing access token")
	\n
	token = auth_header.split(" ")[1]
	try:
	payload = jwt.decode(token, ACCESS_SECRET_KEY, algorithms=[ALGORITHM])
	request.state.user = payload.get("sub")
	except jwt.ExpiredSignatureError:
	raise HTTPException(status_code=401, detail="Access token expired")
	except jwt.PyJWTError:
	raise HTTPException(status_code=401, detail="Invalid access token")
	\n
	response = await call_next(request)
	return response
	\n
	\n
	# Tạo access token
	def create_access_token(username: str):
	expire = int(time.time()) + ACCESS_TOKEN_EXPIRE_SECONDS
	to_encode = {"sub": username, "exp": expire}
	return jwt.encode(to_encode, ACCESS_SECRET_KEY, algorithm=ALGORITHM)
	\n
	\n
	# API login: cấp access và refresh token
	@app.post("/login")
	async def login(username: str):
	access_token = create_access_token(username)
	refresh_token = jwt.encode({"sub": username, "exp": int(time.time()) + 3600},
	REFRESH_SECRET_KEY, algorithm=ALGORITHM)
	return {"access_token": access_token, "refresh_token": refresh_token}
	\n
	\n
	# API logout: revoke refresh token
	@app.post("/logout")
	async def logout(refresh_token: str, request: Request):
	try:
	payload = jwt.decode(refresh_token, REFRESH_SECRET_KEY, algorithms=[ALGORITHM])
	exp = payload.get("exp")
	# Lưu refresh token vào blacklist Redis đến khi hết hạn
	await request.app.state.redis.setex(f"blacklist:{refresh_token}", exp - int(time.time()), "1")
	except jwt.PyJWTError:
	raise HTTPException(status_code=401, detail="Invalid refresh token")
	\n
	return {"msg": "Logged out"}
	\n
	\n
	# API refresh token: cấp access token mới
	@app.post("/refresh")
	async def refresh(refresh_token: str, request: Request):
	redis = request.app.state.redis
	# Kiểm tra refresh token trong blacklist
	if await redis.get(f"blacklist:{refresh_token}"):
	raise HTTPException(status_code=401, detail="Refresh token revoked")
	\n
	try:
	payload = jwt.decode(refresh_token, REFRESH_SECRET_KEY, algorithms=[ALGORITHM])
	username = payload.get("sub")
	new_access_token = create_access_token(username)
	return {"access_token": new_access_token}
	except jwt.ExpiredSignatureError:
	raise HTTPException(status_code=401, detail="Refresh token expired")
	except jwt.PyJWTError:
	raise HTTPException(status_code=401, detail="Invalid refresh token")
	\n
	\n
	# Endpoint cần access token
	@app.get("/protected/data")
	async def protected_data(request: Request):
	return {"msg": f"Hello {request.state.user}, this is protected!"}

\n\n\n

\n\n

\n view raw\n \n jwt_refresh_token.py\n \n hosted with ❤ by GitHub\n

\n","stylesheet":"https://github.githubassets.com/assets/gist-embed-59543e005c9c.css"}" data-component-name="GitgistToDOM">

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

Show hidden characters

	from fastapi import FastAPI, Request, HTTPException, Depends
	from fastapi.responses import JSONResponse
	import jwt
	import time
	import aioredis

	# Secret và cấu hình token
	ACCESS_SECRET_KEY = "mysecret"
	REFRESH_SECRET_KEY = "refreshsecret"
	ALGORITHM = "HS256"
	ACCESS_TOKEN_EXPIRE_SECONDS = 60

	app = FastAPI()

	# Kết nối Redis
	@app.on_event("startup")
	async def startup_event():
	app.state.redis = await aioredis.from_url("redis://localhost")

	@app.on_event("shutdown")
	async def shutdown_event():
	await app.state.redis.close()


	# Middleware kiểm tra access token
	@app.middleware("http")
	async def jwt_middleware(request: Request, call_next):
	if request.url.path.startswith("/protected"):
	auth_header = request.headers.get("Authorization")
	if not auth_header or not auth_header.startswith("Bearer "):
	raise HTTPException(status_code=401, detail="Missing access token")

	token = auth_header.split(" ")[1]
	try:
	payload = jwt.decode(token, ACCESS_SECRET_KEY, algorithms=[ALGORITHM])
	request.state.user = payload.get("sub")
	except jwt.ExpiredSignatureError:
	raise HTTPException(status_code=401, detail="Access token expired")
	except jwt.PyJWTError:
	raise HTTPException(status_code=401, detail="Invalid access token")

	response = await call_next(request)
	return response


	# Tạo access token
	def create_access_token(username: str):
	expire = int(time.time()) + ACCESS_TOKEN_EXPIRE_SECONDS
	to_encode = {"sub": username, "exp": expire}
	return jwt.encode(to_encode, ACCESS_SECRET_KEY, algorithm=ALGORITHM)


	# API login: cấp access và refresh token
	@app.post("/login")
	async def login(username: str):
	access_token = create_access_token(username)
	refresh_token = jwt.encode({"sub": username, "exp": int(time.time()) + 3600},
	REFRESH_SECRET_KEY, algorithm=ALGORITHM)
	return {"access_token": access_token, "refresh_token": refresh_token}


	# API logout: revoke refresh token
	@app.post("/logout")
	async def logout(refresh_token: str, request: Request):
	try:
	payload = jwt.decode(refresh_token, REFRESH_SECRET_KEY, algorithms=[ALGORITHM])
	exp = payload.get("exp")
	# Lưu refresh token vào blacklist Redis đến khi hết hạn
	await request.app.state.redis.setex(f"blacklist:{refresh_token}", exp - int(time.time()), "1")
	except jwt.PyJWTError:
	raise HTTPException(status_code=401, detail="Invalid refresh token")

	return {"msg": "Logged out"}


	# API refresh token: cấp access token mới
	@app.post("/refresh")
	async def refresh(refresh_token: str, request: Request):
	redis = request.app.state.redis
	# Kiểm tra refresh token trong blacklist
	if await redis.get(f"blacklist:{refresh_token}"):
	raise HTTPException(status_code=401, detail="Refresh token revoked")

	try:
	payload = jwt.decode(refresh_token, REFRESH_SECRET_KEY, algorithms=[ALGORITHM])
	username = payload.get("sub")
	new_access_token = create_access_token(username)
	return {"access_token": new_access_token}
	except jwt.ExpiredSignatureError:
	raise HTTPException(status_code=401, detail="Refresh token expired")
	except jwt.PyJWTError:
	raise HTTPException(status_code=401, detail="Invalid refresh token")


	# Endpoint cần access token
	@app.get("/protected/data")
	async def protected_data(request: Request):
	return {"msg": f"Hello {request.state.user}, this is protected!"}

view raw jwt_refresh_token.py hosted with ❤ by GitHub

Lưu trực tiếp access token trong Denylist (Blacklist)

Trong cách nãy, mỗi access token sẽ có một field mới là jti (UUID). Mỗi khi token hết hạn, chúng ta lưu jti vào cache database (Redis) và khi cần kiểm tra tính hợp lệ thì check trong cache.

Ưu điểm là có thể thu hồi ngay lập tức token hết hạn. Nhưng nhược điểm là luôn phải kiêm tra trong cache, và làm mất đi tính stateless của JWT

Thêm token_version cho mỗi user

Mỗi user được gán một token_version (ban đầu là 0). Khi phát hành access token mới, giá trị token_version sẽ được đưa vào payload của JWT. Trong quá trình xác thực, hệ thống sẽ so sánh token_version trong payload của JWT với token_version hiện tại trong cơ sở dữ liệu. Nếu hai giá trị trùng khớp, token hợp lệ; ngược lại, token bị từ chối. Cách làm này đặc biệt hữu ích khi cần đăng xuất người dùng khỏi tất cả thiết bị cùng lúc.

Bom nguyên tử

Khi secret key bị lộ, toàn bộ cơ chế bảo mật dựa trên JWT gần như vô hiệu. Hacker có thể dùng khóa này để tự tạo hoặc chỉnh sửa token, thay đổi payload theo ý muốn và vẫn tạo ra chữ ký hợp lệ. Điều này đồng nghĩa hệ thống không thể phân biệt đâu là token thật, đâu là token giả, gây ra rủi ro nghiêm trọng như chiếm quyền truy cập, leo thang đặc quyền hoặc giả mạo người dùng. Đây được xem là “đòn bom nguyên tử” đối với bảo mật JWT.

Trong trường hợp secret key bị lộ, mọi JWT đã phát hành đều coi như không còn an toàn. Hệ thống bắt buộc phải thu hồi toàn bộ token và yêu cầu tất cả người dùng đăng nhập lại từ đầu để tạo ra các token mới dựa trên secret key đã được thay đổi. Đây là biện pháp duy nhất đảm bảo ngăn chặn việc hacker lợi dụng các token cũ để truy cập trái phép.

Kết luận

Không có một giải pháp “viên đạn bạc” nào có thể áp dụng cho mọi hệ thống khi cần revoke JWT. Mỗi hệ thống sẽ có những yêu cầu và mức độ bảo mật khác nhau, do đó cần cân nhắc lựa chọn hoặc kết hợp nhiều phương pháp như: rút ngắn thời gian sống của access token, sử dụng refresh token, áp dụng cơ chế token_version, hoặc quản lý danh sách token bị thu hồi (blacklist). Việc phối hợp linh hoạt các cách tiếp cận sẽ giúp cân bằng giữa tính bảo mật, trải nghiệm người dùng và hiệu năng hệ thống.

Đọc thêm

https://www.descope.com/blog/post/access-token-vs-refresh-token
https://www.descope.com/blog/post/jwt-logout-risks-mitigations

Cảm ơn bạn đã đọc bài viết này, nếu bạn có bất kỳ câu hỏi nào, đừng ngần ngại để lại comment ở bên dưới. Và đừng quên subscribe để luôn nhận được các bài viết mới nhất