Đấu giá trực tuyến

Đưa toàn bộ luật vào WHERE: status OPEN, end_at > now(), current_price + min_increment <= amount. DB tự khóa hàng trong vài ms và kiểm tra lại điều kiện sau khi chờ, nên chỉ một bid ở mỗi mức giá thắng. Bid thua trả về ngay với giá mới để client hiện cho người dùng. Idempotency-Key chặn việc bấm hai lần.

Đánh đổi: Một hàng chịu được vài trăm bid/s; vượt mức đó thì khóa hàng trở thành nút thắt và cần tuần tự hóa phía trước.

Nguồn: Microservices Patterns ↗ (.zip) · ch.3 · §3.3.7 Transactional messaging ; Chưa có nguồn trong thư viện: UPDATE có điều kiện là kỹ thuật DB chung

Bid được đẩy vào partition Kafka chọn theo auction_id, mỗi partition có đúng một consumer xử lý tuần tự và giữ giá hiện tại trong bộ nhớ, loại ngay bid thấp trước khi ghi DB. Câu UPDATE có điều kiện vẫn giữ làm lớp an toàn cuối.

Đánh đổi: Đặt giá thành bất đồng bộ, client phải chờ kết quả qua SSE; thêm độ trễ và phức tạp nên chỉ đáng khi một phiên thật sự vượt vài trăm bid/s.

Nguồn: Grokking Modern System Design · ch.17 Distributed Messaging Queue ↗ · mục "Ordering of messages" (Strict ordering) ; Chưa có nguồn trong thư viện: single writer theo auction_id là thiết kế của khoá học

Mỗi phiên là một phần tử ZSET với score = end_at (mẫu delayed tasks, Redis in Action §6.4.2). Worker gọi ZRANGEBYSCORE 0 now mỗi 200-500 ms trên bucket của mình, đọc lại DB rồi chạy UPDATE ... WHERE status='OPEN' AND end_at <= now(). Nếu phiên đã được gia hạn thì chỉ cần ZADD lại với end_at mới. ZSET mất dữ liệu thì dựng lại từ index end_at trong DB, đúng như cách Grokking ch.23 tách lưu trữ task và phần thực thi.

Đánh đổi: Thêm một thành phần phải theo dõi độ trễ (lag giữa end_at và lúc đóng); nhưng vì bid path tự chặn bid trễ nên scheduler chậm vài giây chỉ làm thông báo đến muộn, không làm sai kết quả.

Nguồn: Redis in Action ↗ · ch.6 · §6.4.2 Delayed tasks (tr. 137) ; Grokking Modern System Design · ch.23 Distributed Task Scheduler ↗ · mục "Components" (tách lưu task và thực thi)

Sau commit, Bid service publish {price, leader, end_at, seq} lên kênh auction:{id} (Grokking ch.18, Redis in Action §3.6). Gateway chỉ subscribe các phiên mà client của nó đang xem rồi đẩy xuống qua SSE. Phiên quá nóng thì gộp, mỗi 250 ms gửi một bản giá mới nhất. Client so seq để bỏ tin cũ và gọi lại GET khi kết nối lại.

Đánh đổi: Phải vận hành hàng loạt kết nối mở và kênh pub/sub; pub/sub không lưu lại tin nên client luôn cần đường GET để bù.

Nguồn: Grokking Modern System Design · ch.18 Pub-sub ↗ · mục "High-level design" ; Redis in Action ↗ · ch.3 · §3.6 Publish/subscribe

Câu UPDATE đặt giá thêm SET end_at = GREATEST(end_at, now() + interval '2 minutes'), extensions = extensions + 1 khi bid rơi vào 2 phút cuối, kèm giới hạn tổng thời gian gia hạn (ví dụ 30 phút). Ai cũng có 2 phút để đáp trả nên bid giây cuối hết tác dụng. Sự kiện end_extended được đẩy cho mọi người xem; scheduler tự ZADD lại khi thấy end_at đã đổi. Thêm rate limit theo user cho endpoint bid để chặn bot spam.

Đánh đổi: Giờ kết thúc không còn cố định nên người mua khó canh giờ; phải hiển thị rõ luật gia hạn và giới hạn tối đa để tránh phiên kéo dài vô tận.

Nguồn: Chưa có nguồn trong thư viện: soft close là nghiệp vụ đấu giá ; Grokking Modern System Design · ch.19 Rate Limiter ↗ · mục "Where to place the rate limiter"