Kiến trúc Hệ thống Flash Sale: Bài toán kinh điển và Giải pháp tối ưu

Trong các hệ thống thương mại điện tử hoặc ứng dụng giao hàng nhanh (như Hasaki Express, Shopee, Tiki...), Flash Sale luôn là một trong những bài toán thử thách nhất đối với các kỹ sư phần mềm.

Hãy hình dung một kịch bản: Vào khung giờ vàng, hệ thống tung ra một sản phẩm cực hot với số lượng giới hạn chỉ 100 suất. Đột ngột, có hàng chục ngàn người dùng (request) đồng thời nhấn nút "Mua ngay". Nếu thiết kế không tốt, hệ thống không chỉ sụp đổ mà còn dẫn đến thảm họa kinh doanh lớn nhất: Bán âm kho (Overselling).

Dưới đây là phân tích chi tiết về nguyên nhân cốt lõi và hướng giải quyết triệt để cho bài toán này, dựa trên góc nhìn System Design.

1. Chuyện gì sẽ xảy ra nếu dùng Database Quan hệ (RDBMS) thông thường?

Nếu lập trình viên viết code theo "bản năng" — nhận request, query kiểm tra tồn kho trong MySQL/PostgreSQL, dùng code trừ đi 1, rồi update lại và tạo đơn hàng — hệ thống sẽ đối mặt với hai thảm họa kép ở tầng cơ sở dữ liệu:

Bung bét Connection Pool (Quá tải kết nối): Các RDBMS như MySQL hay PostgreSQL được thiết kế để đảm bảo tính toàn vẹn dữ liệu (ACID) chứ không phải để chịu tải hàng vạn kết nối đồng thời. Giới hạn chịu đựng thông thường chỉ ở mức vài nghìn connection. Khi hàng vạn request ập vào cùng lúc, Connection Pool sẽ lập tức cạn kiệt. Các request đến sau phải xếp hàng chờ lấy connection, dẫn đến Timeout, rớt mạng, và cuối cùng là sập toàn bộ dịch vụ.
Tranh chấp tài nguyên (Race Condition) và Bán âm kho: Hàng ngàn transaction cùng đọc một dòng dữ liệu tồn kho (ví dụ: stock = 100) tại cùng một mili-giây. Tất cả đều thấy kho còn hàng, đi qua bước kiểm tra logic, và cùng thực hiện lệnh trừ kho. Kết quả là 10.000 đơn hàng được tạo thành công cho... 100 sản phẩm. Nếu bạn dùng cơ chế khóa (Row-level locking) của DB để ngăn bán âm, DB sẽ phải xếp hàng tuần tự hàng vạn lệnh update đó, gây ra hiện tượng thắt cổ chai (bottleneck) nghiêm trọng, khiến thời gian phản hồi (latency) tăng vọt lên hàng chục giây.

2. Giải pháp Kiến trúc: Nguyên tắc "Lá chắn thép"

Nguyên tắc vàng trong System Design khi đối mặt với lượng traffic khổng lồ là: Tuyệt đối không để một lượng traffic khổng lồ chạm trực tiếp vào database vật lý.

Hệ thống cần được chia làm nhiều tầng để "đỡ đạn" và xử lý bất đồng bộ. Dưới đây là chiến lược 4 bước để xử lý bài toán này.

Bước 1: Dùng Redis làm khiên đỡ đạn & Chống Oversell với `DECR`

Thay vì đọc/ghi trực tiếp vào RDBMS, chúng ta đưa tồn kho lên bộ nhớ đệm (In-memory Cache) có tốc độ phản hồi tính bằng mili-giây.

Warm-up: Trước giờ G, hệ thống sẽ tự động load số lượng tồn kho (100) từ MySQL lên Redis.
Lệnh Atomic: Khi người dùng nhấn nút mua, API lập tức chọc vào Redis và sử dụng lệnh DECR (Decrement) của Redis.
Tuyệt đối an toàn: Lệnh DECR là một lệnh nguyên tử (Atomic) hoạt động trên một luồng (Single-thread) của Redis. Dù có 10.000 người cùng nhấn mua trong 1 mili-giây, Redis vẫn sẽ xếp hàng và trừ một cách tuần tự và chính xác: 100, 99, 98... Ai nhận được kết quả >= 0 thì được đi tiếp. Ai bị trừ xuống < 0 thì hệ thống lập tức báo "Hết hàng" và đá văng ra ngoài. Rủi ro bán âm kho được triệt tiêu 100%.

Bước 2: Dùng Kafka làm Message Queue để hứng Event

Với những user đã lấy được slot (kết quả DECR >= 0), chúng ta không bắt họ phải chờ hệ thống chọc xuống Database để tạo bảng ghi đơn hàng.

Thay vào đó, hệ thống chỉ cần đóng gói một sự kiện (Message: User A mua Sản phẩm B) và ném thẳng vào Kafka (Message Queue).
Ngay khi ném vào Queue thành công, API lập tức trả về phản hồi cho người dùng: "Bạn đã giữ chỗ thành công, hệ thống đang xử lý đơn hàng!". Quá trình này diễn ra cực nhanh, giúp giải phóng luồng xử lý (request thread) ngay lập tức để phục vụ user khác.

Bước 3: Worker xử lý bất đồng bộ (Asynchronous) xuống Database

Kafka giờ đây đóng vai trò như một đập chứa nước, giúp "bơm" dữ liệu xuống Database ở một tốc độ an toàn.

Hệ thống có các background worker liên tục đọc (consume) message từ Kafka.
Các worker này sẽ từ tốn insert dữ liệu vào MySQL/PostgreSQL, khởi tạo đơn hàng, thanh toán, lưu lịch sử... với một lưu lượng connection vừa phải (ví dụ: 100 msg/giây). Database vật lý lúc này hoàn toàn thảnh thơi, an toàn, không bị áp lực từ bão traffic.

Bước 4: Cập nhật Real-time về Client qua WebSockets / SSE

Vì đơn hàng được tạo bất đồng bộ ở phía sau, người dùng cần biết khi nào đơn hàng của họ thực sự hoàn tất (hoặc thất bại do lỗi thanh toán).

Sử dụng WebSockets hoặc SSE (Server-Sent Events) để thiết lập kết nối 2 chiều hoặc đẩy dữ liệu 1 chiều từ server xuống client.
Khi Worker xử lý xong đơn hàng trong DB, nó sẽ bắn một event qua WebSocket báo cho frontend của người dùng hiển thị thông báo pop-up: "Chúc mừng, đơn hàng của bạn đã được tạo thành công!"

3. Ví dụ luồng xử lý (Workflow) bằng Code Pseudo / Node.js

Dưới đây là một mô phỏng luồng xử lý tại tầng API Checkout để bạn dễ hình dung sự kết hợp giữa Redis và Kafka:

JavaScript

const Redis = require('ioredis');
const redis = new Redis();
const kafka = require('./kafkaProducer'); 

// Tên key trong Redis lưu tồn kho sản phẩm ID: 999
const PRODUCT_KEY = 'flashsale_stock_999';

async function handleCheckoutRequest(req, res) {
    const userId = req.user.id;
    const productId = req.body.productId;

    try {
        // 1. Dùng lệnh DECR để trừ tồn kho ngay trên RAM
        const remainingStock = await redis.decr(PRODUCT_KEY);

        if (remainingStock < 0) {
            // Hết hàng! Đá văng các request đến chậm.
            return res.status(400).json({ 
                success: false, 
                message: "Rất tiếc, sản phẩm đã bán hết!" 
            });
        }

        // 2. Nếu >= 0, user đã trúng slot. Đẩy event vào Kafka
        const orderEvent = {
            userId: userId,
            productId: productId,
            timestamp: Date.now()
        };
        
        await kafka.send('order_events_topic', JSON.stringify(orderEvent));

        // 3. Trả về kết quả ngay lập tức cho client
        return res.status(202).json({ 
            success: true, 
            message: "Bạn đã giữ suất thành công. Đơn hàng đang được tạo!" 
        });

    } catch (error) {
        console.error("Lỗi hệ thống:", error);
        res.status(500).send("Hệ thống đang bận, vui lòng thử lại!");
    }
}

Tổng kết lại: Bằng cách biến đổi mô hình từ Xử lý đồng bộ (Synchronous) sang Xử lý bất đồng bộ (Asynchronous), kết hợp cùng sức mạnh thao tác trên RAM của Redis và khả năng đệm tải của Kafka, chúng ta đã giải quyết trọn vẹn bài toán Flash Sale. Hệ thống không chỉ đáp ứng được độ trễ cực thấp (low latency) mà còn bảo vệ an toàn tuyệt đối cho hệ thống cơ sở dữ liệu phía sau.

chia sẻ