Sắp bị đuổi việc vì hệ thống chậm lấy shopee làm ví dụ

Nội dung bài viết

Đây là một trong những bài toán kinh điển để xây dựng một hệ thống thương mại điện tử chính thống như Shopee. Bài viết này sẽ trình bày cho các bạn một bài toán khó và chúng ta sẽ lấy Shopee làm ví dụ, và có thể nói họ đã giải quyết bài toán này rất tốt chứ không phải là khá tốt.


Kịch bản bài toán thương mại Shopee


"Bạn đã bao giờ mua trên shopee bao giờ chưa?" Nếu có, tôi hỏi tiếp "Vậy bạn có khi nào mua vào lúc Shopee mở bán vào lúc khung giờ vàng chưa?". Nếu có bạn đọc tiếp bài viết này, nếu không thì bạn cũng nên đọc. Nói chung là nên đọc. 


Khung giờ vàng ở đây mà tôi nói đó chính là ai nhanh đặt hàng người đó được mua bởi số lượng là có hạn. Có thể đói với người mua, họ chỉ quan tâm đến mua được hàng hay không thôi. Nhưng đối với những người phát triển hệ thống Shopee có lẽ nguy cơ mất việc từ những KHUNG GIỜ VÀNG đó. Vì sao hãy cùng theo dõi câu chuyện dưới đây. 


Câu chuyện đặt hàng shopee của một Lập Trình Viên


Bạn nên nhớ bất kỳ một hệ thống nào cũng phát triển từ nhỏ đến to. Không ai có thể phát triển một lúc hết các tính năng và đồng thời phục vụ hàng triệu người cùng một lúc (high concurrency). 


Chính vì vậy khi Shopee còn rất nhỏ thì ban đầu quy trình đặt hàng của họ rất đơn giản, đó chính là: Sau khi đặt hàng và thanh toán, quy trình đã hoàn tất. Tuy nhiên, shopee làm truyền thông rất tốt và lượng người dùng tăng lên theo thời gian và tình hình như thế này họ cần một GIÁM ĐỐC phát triển sản phẩm có tầm cỡ. Và cuối cùng cũng tìm ra anh ta. 


Khi bắt tay vào công việc thì anh ta đã thiết lập một hệ thống đặt hành theo quy chuẩn của hiện đại. Thật ra thì thương mại điện tử chính thống sẽ có nhiều hơn 10 bước trong quy trình đặt hàng. 


Đầu tiên anh ta cho phép và thiết lập một hệ thống phiếu giảm giá cho sản phẩm. Nghĩa là lúc đầu hệ thống chỉ có đặt và thanh toán chỉ mất 100ms là xong. Nhưng giờ đây có thêm chức năng khấu trừ phiếu giảm giá nữa, thì hiện tại hệ thống phải mất thêm 100ms nữa. OK không sao, nói chung là 200ms phản hồi yêu cầu là quy chuẩn quá tốt. 


Bước thứ hai anh GIÁM ĐỐC này quyết định xây dựng hệ thống tích điểm (Xu) cho mỗi đơn hàng được đặt thành công. Team code nói được rồi, có thêm 200ms trong quá trình tăng hoặc giảm điểm của mỗi đơn hàng cho người dùng. Mấy rồi, 400 ms rồi phải không? Chưa hết đâu 


Sau đó anh ta còn muốn khi người dùng đặt hàng thành công ngoài những bước trên thì muốn gửi cho người dùng một email và kèm theo đó là những sản phẩm đi cùng, đại khái là gợi ý sản phẩm mua chung. OK luôn, thêm 200ms nữa cho thao tác này. Sau đó thêm vài bước nữa như tôi nói ở trên là mất hơn 10 quy trình đặt hàng cho một hệ thống thương mại lớn. 


Đại khai mô hình nó như thế này. 

Quy trình này cứ tiếp tục như vậy và mất rất nhiều thời gian. Người dùng thấy rằng phải mất hàng chục giây để mua thứ gì đó cho bạn. Và đương nhiên họ sẽ từ chối đặt hàng khi hệ thống chạm như vậy? 


Cách giải quyết của lập trình viên như thế nào?


Đó là một trong những bài toán kinh điển, thật ra nó không mới về công nghê hay đã có nhiều giải pháp. Nhưng tôi muốn các bạn mới hiểu hơn về quy trình thiết kế một hệ thống lỡn, nó được triển khai một cách tỉ mỉ từng giai đoạn, và trong đó có bao nhiêu công nghệ đã được áp dụng. Vậy nếu là bạn, bạn xử lý như thế nào cho hệ thống nhanh, gọn, hiểu quả nhưng quan trọng là chi phí ít. 


Nếu bạn hóng tiếp thì tôi sẽ giới thiệu một công nghệ mà bất cứ hệ thống nào cũng phải sử dụng. Nếu bạn muốn biết tôi đã xử lý thế nào thì tiếp tục bài viết tiếp theo ở đây. "Công nghệ đã giúp tôi thoát khỏi thất nghiệp"

Có thể bạn đã bị missing