Design System: Payment System cơ bản - 3k RPS
HTML-код
- Опубликовано: 30 сен 2024
- Mình có nhận được một câu hỏi liên quan tới Design System từ một thành viên trong nhóm chia sẻ về SA & Design System. Đây là một câu hỏi trong 1 buổi phỏng vấn (có thể là backend/system) của bạn ấy.
Mình thiết kế hệ thống này dựa trên phần requirement bạn ấy cung cấp. Đây có thể chỉ là phối hợp một số pattern thường xuất hiện trong hệ thống lớn, không phải một best practice. Trong thực tế, các bạn nên hỏi đáp với interviewer thêm để hiểu được context, nghiệp vụ cụ thể cũng như các non-functional requirements nhé.
Những kiến thức để thiết kế System như này , nếu không có cơ hội được làm việc trong project thì có cơ may nào để tự học, tự tìm hiểu k a? Dạ e cảm ơn a nhiều
Khi đọc req cho thì thấy họ có nói đến resource limit, nếu không giải thích gì thêm thì mình có được assume là load balancer, api gateway, caching, k8s , messaging system sẽ tồn tại trước và sẽ không sử dụng 6 servers của mình hay sao anh?
Why write content in english but speak in Vietnamese ? English audio is more reachable isnt ?
mình main front end hơn, cho mình hỏi là nếu như những bài toán như này thì giải pháp nó thiên về cơ sở hạ tầng hay là coding flow nhỉ :D
Ở consumer app có thể invalid cache để tầng api lấy lại balance mới nhất là được r chứ nhỉ. Dùng cdc để đọc làm event trigger thì có vẻ ban đầu khi phát triển ứng dụng có vẻ sẽ debug khó hơn
Cám ơn anh bài share rất hay .Anh Việt ơi anh có thể làm 1 seri thiết kế hệ thống microservices k anh . Em cám ơn anh
A sẽ cân nhắc, cảm ơn em.
@@viettx Có chưa a ?
Cảm ơn anh đã chia sẻ, em mới đang tìm hiểu về cách thiết kế hệ thống và chưa có chút kinh nghiệm gì trong hệ thống phức tạp như này, sau khi xem thì em có vài câu hỏi, anh có thể giải đáp giúp em không ạ:
- Anh có nói là "idempotent service sẽ tạo ra 1 key cho mỗi order", thế tại sao mình không dùng luôn order id ạ?
- Trong lúc đang xử lí ở checkout consumer, user gọi lại api checkout thì chuyện gì sẽ xảy ra
- Anh có nói là trong payment.created có rất nhiều message khác, thì liệu mình có thể có nhiều payment.created queue không ạ?
- Ở trong checkout consumer mình không kiểm tra lại balance ạ? Liệu có khả năng khi tạo payment.created thì balance đủ nhưng khi vừa đưa sang consumer thì balance không đủ không ạ?
Cảm ơn em đã đặt các câu hỏi, một các ngắn gọn thì:
1. Idempotent key mục đích để nhận diện user đang truy vấn để lấy desire state của order hay không. Trong thực tế (VD với case của AirBnB), họ sẽ bắt user gọi API để gen key trước sau đó mới dùng key này để thực hiện payment. Như vậy sẽ clear và hệ thống bớt nhọc hơn.
2. Khi đã có Idempotent key, chúng ta return về trạng thái order thay vì thực hiện checkout tiếp -> sẽ bị double spending.
3. Về topic thì mình chỉ có payment.created, trong trường hợp câu hỏi của em thì mình tăng số lượng partition lên (nếu em dùng Kafka). Còn nếu em dùng queue thì cứ tăng số lượng consumer instance lên để tăng tốc xử lý.
4. Trong trường hợp sử dụng SAGA pattern dạng này thì chúng ta check balance và trừ balance ở chỗ consumer xử lý cái created em nhé, đương nhiên là có invalid cache luôn nha, để đảm bảo e có thể dùng store procedure DB hoặc distributed lock để hỗ trợ. Lưu ý là chúng ta không xử lý việc này ở trước khi có message created nhé, vì có lỗi sẽ rất nguy hiểm.
Trong thiết kế này là để phục vụ non-functional requirement (chịu tải read và write) là chính, nên phần logic chi tiết của checkout sẽ không có trong này.
Em chào Anh,
+, Anh cho em hỏi khi thiết kế theo Event-Sourcing Patterns thì các event khi emit có phải lưu trong database không ạ?
+, Trong trường hợp lưu trong database thì dùng database nào để optimize ạ, em có search thì thấy có EventStoreDb.
+, Và nếu lưu event thì nên lưu trong một big db luôn hay trong mỗi service có một database riêng cho event.
Em cảm ơn Anh.
1. Event Sourcing chắc chắn cần persistent em nhé.
2. Event Sourcing có đặc tính chỉ append (thêm record mới) chứ không xoá và sửa, vì thế e có thể dùng các DB tối ưu cho việc này, thường là cần tốc độ write cao. Có thể dùng Kafka, Elastic Search, EventStoreDB,... Thêm nữa là cấu trúc của Event của em có cấu trúc hay phi cấu trúc mà lựa chọn phù hợp nha.
3. Event Sourcing data thường có vol rất lớn, tốc độ tăng tiến dữ liệu nhanh nên một big table/db cho tất cả sẽ không hợp lý. Đương nhiên là từ service này không thể đi lấy event sourcing của service khác.
@@viettx em cảm ơn ạ
Cám ơn những chia sẻ bổ ích của anh 🎉
Cám ơn bạn đã chia sẻ. Cho mình hỏi chỗ open 250 connections ảnh hưởng đến design như nào ?
Đó là giới hạn tối đa số connections đến DB, từ đó phải scale DB (replication, slave/master, partition).
quá hay luôn anh
Dạ cho em hỏi anh dùng tool gì để test RPS vậy ạ?
Locust, k6, tsung,...
Đơn giản nhất là có wrk hoặc wrk2 (câu lệnh terminal đơn giản) để stress/load test em nhé.
@@viettx cảm ơn anh
A có thể tạo 1 danh sách phát về design system được k ạ ?
Cảm ơn anh rất nhiều ạ. ❤
HAY QUÁ
Cảm ơn anh đã chia sẻ ạ
Web a dùng để design là gì vậy ạ
excalidraw.com/
@@viettx libraries bạn đang dùng là gì thế
@@binhnguyenthanh5084 mình lấy từ lib software/system design nằm trong danh mục sẵn có.