Medusa (2)

Làm sao để đảm bảo khi tạo đơn hàng, nếu trừ kho lỗi thì đơn hàng phải bị hủy?

tôi sẽ sử dụng Medusa Workflow. Tôi định nghĩa bước 1 là tạo đơn, bước 2 là trừ kho. Nếu bước 2 lỗi, Workflow sẽ tự động thực hiện Compensating Action để xóa đơn hàng vừa tạo ở bước 1.

Medusa giới thiệu Workflows để xử lý các nghiệp vụ phức tạp (như Checkout, Đổi trả hàng).

• Tại sao: Khi một Workflow chạy, nó gồm nhiều bước (Steps). Redis lưu trữ trạng thái (State) của từng bước. Nếu Server bị sập giữa chừng, khi khởi động lại, Medusa sẽ nhìn vào Redis để biết Workflow đang dừng ở đâu để chạy tiếp hoặc chạy hàm "Hoàn tác" (Compensating Action).

• Usecase: Khách hàng đang thanh toán, bỗng nhiên server bảo trì. Khi server sống lại, Redis giúp hệ thống biết đơn hàng này đã trừ tiền chưa để tiếp tục tạo vận đơn.

Event Bus (Cơ chế hướng sự kiện)

Medusa v2 dựa rất mạnh vào kiến trúc Asynchronous (Bất đồng bộ).

• Tại sao: Các Module trong v2 (Product, Order, Inventory) hoạt động độc lập. Khi Module Order tạo đơn xong, nó bắn một "sự kiện" vào Redis. Các Module khác "đăng ký" lắng nghe sự kiện đó để làm việc của mình.

• Usecase: Khi có đơn hàng mới (order.placed), Redis đẩy thông báo cho Notification Module để gửi Email và đẩy cho Inventory Module để trừ kho ngầm, giúp người dùng không phải chờ đợi trên giao diện.

Distributed Locking (Khóa phân tán)

Vì Medusa v2 được thiết kế để mở rộng (Scalability), bạn có thể chạy nhiều Server cùng lúc.

• Tại sao: Tránh tình trạng Race Condition (nhiều tiến trình cùng tranh giành một tài nguyên).

• Usecase: Hai khách hàng cùng bấm mua cái áo cuối cùng vào cùng một mili giây. Redis sẽ tạo một cái "khóa" (Lock). Ai đến trước thì lấy được khóa, người đến sau phải đợi hoặc nhận thông báo hết hàng. Điều này cực kỳ quan trọng để tránh bán quá số lượng (Overselling).

Why is Redis essential for Medusa v2 Workflows?

It stores the execution state of workflows. This allows for retries, timeouts, and reliable rollbacks if a step fails.

(Nó lưu trạng thái thực thi của workflow. Điều này cho phép thử lại, xử lý timeout và hoàn tác tin cậy nếu một bước bị lỗi.)

What is the "Event Bus" role of Redis in v2?

It acts as a message broker between isolated modules, allowing them to communicate asynchronously without being tightly coupled.

(Nó đóng vai trò là bên môi giới tin nhắn giữa các module cô lập, cho phép chúng giao tiếp bất đồng bộ mà không bị dính chặt vào nhau.)

Usecase of Redis Distributed Locking in Medusa?

Preventing Race Conditions, such as two customers buying the last item at the exact same time.

(Ngăn chặn tình trạng tranh chấp, ví dụ như hai khách hàng cùng mua mặt hàng cuối cùng tại cùng một thời điểm.)

"Nếu tôi không cài Redis mà dùng Medusa v2 thì có chạy được không?"

Trả lời: "Trong môi trường Development, Medusa v2 có thể dùng In-memory (Lưu vào RAM của chính Node.js) để thay thế. Tuy nhiên, trong Production, bắt buộc phải có Redis. Vì nếu không có Redis, khi Server restart, toàn bộ trạng thái của các Workflow đang chạy sẽ bị mất, và bạn không thể chạy nhiều instance của Medusa cùng lúc vì không có cơ chế đồng bộ sự kiện giữa các server."

Bạn thấy giải thích về "Hệ thần kinh" Redis này đã đủ để bạn tự tin phản biện chưa?

Người phỏng vấn sẽ không hỏi "Redis là gì", họ sẽ hỏi: "Tại sao bước này lại cần Redis và nếu không có nó thì hệ thống chết ở đâu?"

1. Usecase 1: Workflow "Saga" State (Lưu trạng thái quy trình)

Đây là điểm mới nhất của v2. Khi bạn chạy một Workflow phức tạp (ví dụ: Checkout), Redis lưu lại "Nhật ký" thực hiện.

• Kịch bản: Workflow gồm: Trừ kho -> Thanh toán -> Gửi Email.

• Nếu Server sập ở bước Thanh toán: Khi server restart, Medusa nhìn vào Redis và thấy: "À, bước Trừ kho đã xong, bước Thanh toán đang dở dang".

• Câu hỏi phỏng vấn: "Làm sao Medusa biết đường mà Rollback (hoàn tác) nếu server bị crash đột ngột khi đang chạy nửa chừng một Workflow?"

• Trả lời: "Nhờ vào Workflow Engine sử dụng Redis để lưu trữ checkpoint. Mỗi bước hoàn thành đều được ghi nhận (persisted) vào Redis, cho phép khôi phục trạng thái và chạy hàm compensate (hoàn tác) chính xác."

Usecase 2: Idempotency Key (Chống trùng lặp)

Trong thương mại điện tử, việc khách hàng bấm "Thanh toán" 2 lần do mạng lag là cực kỳ nguy hiểm.

• Cơ chế: Medusa tạo ra một Idempotency-Key lưu trong Redis với một khoảng thời gian hết hạn (TTL).

• Câu hỏi phỏng vấn: "Làm sao bạn ngăn chặn việc một Webhook từ Stripe gửi về 2 lần khiến đơn hàng bị xử lý thành 2 đơn?"

• Trả lời: "Tôi sử dụng Idempotency Key lưu trong Redis. Khi request đầu tiên đến, Medusa lưu key đó vào Redis với trạng thái processing. Nếu request thứ 2 đến cùng key đó, Medusa sẽ thấy key đã tồn tại và bỏ qua hoặc trả về kết quả của request đầu tiên."

secase 3: Scheduled Jobs (Nhiệm vụ định kỳ)

v2 sử dụng BullMQ (một thư viện chạy trên nền Redis) để quản lý hàng đợi.

• Usecase: 12 giờ đêm mỗi ngày cần quét các đơn hàng chưa thanh toán để hủy.

• Câu hỏi phỏng vấn: "Nếu tôi chạy 3 instance (3 server) Medusa cùng lúc, làm sao để cái Job quét đơn hàng chỉ chạy đúng 1 lần mà không phải cả 3 server cùng quét?"

• Trả lời: "Medusa dùng Redis-based Job Queue (BullMQ). Redis đóng vai trò bộ điều phối (Coordinator). Khi một Job đến giờ chạy, chỉ có một 'Worker' trên một server chiếm được 'Lock' từ Redis để thực thi, đảm bảo tính duy nhất (Exclusive execution)."

Why is Redis preferred over Postgres for Workflows?

Redis provides low-latency and atomic operations, which are better for tracking rapid state changes than disk-based SQL updates.

(Redis cung cấp độ trễ thấp và các thao tác nguyên tử, tốt hơn cho việc theo dõi thay đổi trạng thái nhanh so với cập nhật SQL trên ổ đĩa.)

What happens to a Medusa v2 Workflow if Redis is cleared?

The system loses track of in-progress workflows. Active transactions cannot be resumed or automatically rolled back.

(Hệ thống mất dấu các workflow đang chạy. Các giao dịch đang hoạt động không thể tiếp tục hoặc tự động hoàn tác.)