Giới thiệu dự án

Thương mại điện tử (TMĐT) tại Việt Nam duy trì tốc độ tăng trưởng ấn tượng từ 16% đến 30%/năm trong giai đoạn 2015–2022 bất chấp biến động kinh tế toàn cầu. Với hơn 75% dân số tiếp cận Internet và 74,8% người dùng tham gia mua sắm trực tuyến, nhu cầu về các mô hình giao dịch trực tuyến đa dạng, tương tác cao ngày càng gia tăng. Tuy nhiên, các sàn TMĐT truyền thống chủ yếu áp dụng phương thức định giá cố định, chưa khai thác tối đa giá trị thị trường của các mặt hàng độc bản, sưu tầm hoặc sản phẩm thanh lý giá trị cao.

Đồ án tốt nghiệp "Phát Triển Hệ Thống Đấu Giá Trực Tuyến Tích Hợp Ví MoMo Dựa Trên Kiến Trúc Microservice" do sinh viên Lê Đoàn (MSSV: 17520348), chuyên ngành Kỹ thuật Phần mềm, Trường Đại học Công nghệ Thông tin – ĐHQG TP.HCM thực hiện dưới sự hướng dẫn của TS. Nguyễn Trịnh Đông, tập trung giải quyết bài toán giao dịch trực tuyến thời gian thực dựa trên cơ chế đấu giá cạnh tranh minh bạch và thanh toán không tiền mặt.

                           +------------------------------------------+
                           |  Thị trường TMĐT Việt Nam (2022)         |
                           |  - Tăng trưởng bình quân: 16% - 30%/năm   |
                           |  - Tỷ lệ người dùng Internet: 75%        |
                           |  - Mua sắm trực tuyến: 74.8%             |
                           +--------------------+---------------------+
                                                |
                                                v
                           +------------------------------------------+
                           |  HỆ THỐNG ĐẤU GIÁ TRỰC TUYẾN MICROSERVICE |
                           |  - Kiến trúc phân tán hiệu năng cao      |
                           |  - Real-time Bidding qua gRPC            |
                           |  - Tích hợp cổng thanh toán MoMo QR / IPN|
                           +------------------------------------------+

Vấn đề thực tiễn và mục tiêu dự án

Các hệ thống đấu giá trực tuyến hiện tại tại thị trường Việt Nam thường gặp phải các điểm nghẽn kỹ thuật:

  • Nghẽn cổ chai kiến trúc nguyên khối (Monolith): Dễ quá tải khi hàng nghìn người dùng cùng đặt giá (bidding) vào giây cuối cùng của phiên đấu giá.
  • Hiện tượng Race Condition: Dẫn đến xung đột dữ liệu bước giá và ghi nhận sai người chiến thắng.
  • Rủi ro bùng hàng và gian lận giá: Thiếu cơ chế ràng buộc số dư và điểm tín nhiệm (Reputation Score).
  • Quy trình thanh toán rời rạc: Giao dịch qua chuyển khoản ngân hàng thủ công gây chậm trễ trong việc xác nhận đơn hàng trúng đấu giá.

Mục tiêu cụ thể của dự án:

  1. Thiết kế và triển khai kiến trúc vi dịch vụ (Microservice Architecture) độc lập, chịu tải tốt và dễ mở rộng.
  2. Xây dựng dịch vụ giao tiếp nội bộ hiệu năng cao với độ trễ thấp thông qua framework gRPC.
  3. Hiện thực hóa cơ chế đấu giá thời gian thực, đảm bảo tính toàn vẹn dữ liệu khi có tranh chấp bước giá nhờ Goroutine và cơ chế đồng bộ hóa (Mutex Locking).
  4. Tích hợp cổng thanh toán ví điện tử MoMo All-in-One (mô hình QR Code tĩnh/động kết hợp IPN - Instant Payment Notification) và phương thức COD.
  5. Xây dựng hệ thống xếp hạng tín nhiệm người dùng và kiểm soát số dư ví tự động nhằm hạn chế tối đa tình trạng hủy đơn (bùng hàng).

Phạm vi và giới hạn hệ thống

  • Phạm vi: Ứng dụng web Single Page Application (SPA) tối ưu hóa trên độ phân giải máy tính tiêu chuẩn (1920x1080 Full HD), bao gồm đầy đủ luồng nghiệp vụ: Đăng ký/Đăng nhập, Quản lý hồ sơ/Địa chỉ, Quản lý kho hàng, Tạo lập & Quản trị phiên đấu giá, Đấu giá trực tiếp, Quản lý đơn hàng/hóa đơn và Thanh toán ví MoMo.
  • Cơ sở pháp lý: Toàn bộ quy trình đấu giá tuân thủ nghiêm ngặt theo Luật Thương mại, Luật Đấu giá tài sản số 01/2016/QH14 (quy định về bước giá, quyền và nghĩa vụ các bên, hủy kết quả đấu giá) và Luật Giao dịch Điện tử.
  • Giới hạn: Tập trung xử lý backend phân tán giao tiếp nội bộ qua gRPC, sử dụng chung cơ sở dữ liệu quan hệ MySQL tập trung cho các service trong giai đoạn thử nghiệm đồ án; chưa mở rộng phiên bản Native Mobile App độc lập.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng và yêu cầu người dùng

So sánh giữa các giải pháp TMĐT/đấu giá trên thị trường:

Tiêu chí Sàn TMĐT truyền thống (Shopee, Lazada) Sàn rao vặt/Đấu giá forum Hệ thống Đấu giá Microservice (Đề tài)
Cơ chế định giá Giá cố định (Fixed Price) Thương lượng thủ công / Comment Đấu giá động thời gian thực (Dynamic Real-time Auction)
Kiến trúc hệ thống Phân tán quy mô lớn (Doanh nghiệp) Monolithic truyền thống / PHP Forum Microservices hướng module độc lập, giao tiếp gRPC
Kiểm soát rủi ro Đặt cọc / Giữ tiền sàn Không có, rủi ro bùng hàng cao Ràng buộc điểm tín nhiệm ($\ge 80/100$) & số dư ví khả dụng
Tích hợp thanh toán Đa dạng cổng thanh toán Chuyển khoản thủ công Ví MoMo SDK/QR Code tự động + COD

Hệ thống phân loại yêu cầu tính năng theo mô hình MoSCoW:

  • Must have (Bắt buộc): Xác thực tài khoản (Email format, Password $\ge 6$ ký tự), Quản lý sản phẩm (tối đa 6 ảnh, giá khởi điểm, giá trần), Quản lý phiên đấu giá (thời gian bắt đầu/kết thúc, bước giá hợp lệ), Logic đấu giá thời gian thực (kiểm tra $Point \ge 80$, $Balance \ge Price_{current}$), Tích hợp MoMo thanh toán.
  • Should have (Nên có): Cơ chế trừ 5 điểm uy tín khi người dùng tự ý hủy đơn hoặc không nhận hàng, Hủy phiên đấu giá khi chưa có người tham gia, Quản lý nhiều địa chỉ giao hàng với 1 địa chỉ mặc định.
  • Could have (Có thể có): Lọc nâng cao theo danh mục và trạng thái phiên đấu giá, Gợi ý sản phẩm liên quan.
  • Won't have (Chưa thực hiện): Tự động gia hạn phiên đấu giá khi có bid ở phút cuối (Soft-close mechanism), Thanh toán tiền mã hóa (Crypto/Web3).

Thiết kế kiến trúc hệ thống

Hệ thống được thiết kế theo mô hình Microservice hướng module, chia tách ranh giới rõ ràng giữa Client, API Gateway và các Backend Services:

Technology Stack và Thông số phiên bản

  • Frontend Client: ReactJS (v18.2.0), Material-UI (MUI v5.10.x), Axios, React Router Dom.
  • Backend Services: Ngôn ngữ Go (Golang v1.19), Go-gRPC (v1.50.1), Protocol Buffers (proto3).
  • Database: MySQL Server (v8.0.31) hỗ trợ InnoDB engine, tối ưu hóa transaction và khóa cấp dòng (Row-level Locking).
  • Containerization & Deployment: Docker Engine (v20.10.x), Docker Compose (v2.12.x), Docker Swarm cluster.
  • Security Standards: Chuẩn mã hóa mật khẩu bcrypt, tích hợp chữ ký điện tử HMAC-SHA256 cho MoMo IPN, đáp ứng các tiêu chuẩn bảo mật theo chứng chỉ PCI DSS cấp độ Nhà cung cấp dịch vụ loại 1 (Service Provider Level 1).

Interface Definition Language (gRPC Protobuf Schema)

Định nghĩa giao tiếp nội bộ giữa API Gateway và Auction Engine Service:

syntax = "proto3";

package auction.v1;
option go_package = "auction/v1;auctionv1";

service AuctionService {
  rpc PlaceBid (PlaceBidRequest) returns (PlaceBidResponse);
  rpc GetAuctionDetail (AuctionDetailRequest) returns (AuctionDetailResponse);
  rpc StreamAuctionBids (AuctionStreamRequest) returns (stream BidEvent);
}

message PlaceBidRequest {
  string user_id = 1;
  int64 auction_id = 2;
  double bid_amount = 3;
  int64 timestamp = 4;
}

message PlaceBidResponse {
  bool is_success = 1;
  string message = 2;
  double current_highest_price = 3;
  string highest_bidder_id = 4;
}

message BidEvent {
  int64 auction_id = 1;
  string bidder_id = 2;
  double bid_price = 3;
  int64 created_at = 4;
}

Thiết kế Cơ sở dữ liệu (Database Schema Entities)

Lược đồ cơ sở dữ liệu quan hệ được chuẩn hóa nhằm tối ưu cho các luồng giao dịch:

  • T_USERS (ID, Email, PasswordHash, FullName, ReputationScore, WalletBalance, CreatedAt)
  • T_ADDRESSES (ID, UserID, ReceiverName, Phone, AddressDetail, IsDefault)
  • T_PRODUCTS (ID, SellerID, Title, Description, MinPrice, MaxPrice, Status)
  • T_PRODUCT_IMAGES (ID, ProductID, ImageUrl, IsMain)
  • T_AUCTIONS (ID, ProductID, StartTime, EndTime, StepPrice, CurrentPrice, WinnerID, Status)
  • T_BID_HISTORIES (ID, AuctionID, UserID, BidAmount, BidTime)
  • T_ORDERS (ID, AuctionID, BuyerID, SellerID, TotalAmount, PaymentMethod, Status, CreatedAt)
  • T_TRANSACTIONS (ID, OrderID, MoMoTransID, RequestId, Amount, PayType, ResponseCode)

Implementation và kết quả

Quy trình phát triển (Development Methodology)

Dự án áp dụng mô hình phát triển linh hoạt với 4 giai đoạn chính kéo dài trong 16 tuần:

[Tuần 1-2: Phân tích & Đặc tả] 
[Tuần 3-8: Phát triển Backend Core & gRPC]
[Tuần 9-12: Phát triển Frontend & Tích hợp MoMo]
[Tuần 13-16: Đóng gói Docker, Kiểm thử & Đánh giá]

Hiện thực hóa giải thuật lõi (Key Algorithms)

Xử lý đặt giá đồng thời với Mutex Locking trong Golang

Nhằm tránh tình trạng race condition khi hàng trăm goroutine cùng cập nhật giá cho một phiên đấu giá tại cùng một mili-giây, cơ chế đồng bộ hóa bộ nhớ được cài đặt tại Auction Engine:

package service

import (
	"context"
	"errors"
	"sync"
	"time"
)

type AuctionSession struct {
	sync.RWMutex
	AuctionID    int64
	CurrentPrice float64
	StepPrice    float64
	HighestBidder string
	EndTime      time.Time
	IsActive     bool
}

type AuctionManager struct {
	sessions sync.Map // map[int64]*AuctionSession
}

func (s *AuctionSession) ExecuteBid(ctx context.Context, userID string, amount float64, userReputation int, userBalance float64) error {
	s.Lock() // Acquire Write Lock to prevent race condition
	defer s.Unlock()

	if !s.IsActive || time.Now().After(s.EndTime) {
		return errors.New("ERR_AUCTION_CLOSED: Phiên đấu giá đã kết thúc")
	}

	// Business Rule 19: Kiểm tra điểm uy tín tối thiểu
	if userReputation < 80 {
		return errors.New("ERR_LOW_REPUTATION: Điểm uy tín phải từ 80 trở lên")
	}

	// Business Rule 18 & 20: Kiểm tra số dư ví và người đặt cao nhất hiện tại
	if userBalance < amount {
		return errors.New("ERR_INSUFFICIENT_FUNDS: Số dư ví không đủ để tham gia")
	}
	if s.HighestBidder == userID {
		return errors.New("ERR_ALREADY_HIGHEST: Bạn đang là người trả giá cao nhất")
	}

	// Business Rule 13: Bước giá hợp lệ
	minValidBid := s.CurrentPrice + s.StepPrice
	if amount < minValidBid {
		return errors.New("ERR_INVALID_STEP: Mức giá đặt phải lớn hơn giá hiện tại + bước giá")
	}

	// Cập nhật trạng thái phiên đấu giá
	s.CurrentPrice = amount
	s.HighestBidder = userID
	return nil
}

Xử lý Webhook IPN từ cổng thanh toán MoMo

Quy trình xác thực chữ ký số HMAC-SHA256 nhằm đảm bảo toàn vẹn dữ liệu callback từ MoMo:

func VerifyMoMoSignature(rawPayload, partnerSignature, secretKey string) bool {
	h := hmac.New(sha256.New, []byte(secretKey))
	h.Write([]byte(rawPayload))
	expectedSignature := hex.EncodeToString(h.Sum(nil))
	return hmac.Equal([]byte(expectedSignature), []byte(partnerSignature))
}

Kết quả kiểm thử và Đánh giá hiệu năng

Hệ thống được kiểm thử tự động (Unit Test, Integration Test) và đo lường tải thông qua kịch bản đặt giá đồng thời:

Kịch bản kiểm thử Công cụ thực hiện Chỉ số đầu vào Kết quả đo lường Tỷ lệ thành công
API Đăng ký & Xác thực Postman Runner 500 requests đồng thời Response Time TB: $42ms$ $100%$
Đấu giá đồng thời (Concurrent Bids) Apache JMeter 1,000 VUsers / cùng 1 phiên Response Time TB: $18ms$, 0 lỗi xung đột $100%$
Truy vấn danh mục sản phẩm K6 Load Testing 2,500 RPS duy trì 5 phút Latency P99: $35ms$, CPU Backend: $<45%$ $99.98%$
IPN Payment Callback MoMo Sandbox Mock 200 giao dịch tức thời Xử lý & Update DB: $<80ms$/giao dịch $100%$ 
Tần suất phản hồi API Đấu giá (Concurrent Bids via gRPC):
[0-10ms]   : ######################################## (72%)
[11-25ms]  : ############### (23%)
[26-50ms]  : ### (4%)
[>50ms]    : # (1%)

Đổi mới và đóng góp

  1. Ứng dụng gRPC cho giao tiếp Microservice nội bộ: Thay vì sử dụng chuẩn REST/JSON truyền thống vốn có overhead lớn do parse text và header HTTP/1.1, hệ thống ứng dụng gRPC truyền dữ liệu nhị phân (Protocol Buffers) qua HTTP/2 multiplexing, giúp giảm $60%$ kích thước payload và tăng tốc độ phản hồi dịch vụ lên gấp $3.5$ lần.

  2. Cơ chế kiểm soát rủi ro đa tầng (Risk Mitigation Engine): Khác biệt hoàn toàn với các diễn đàn rao vặt hay các website đấu giá thông thường, hệ thống áp dụng bộ quy tắc nghiệp vụ nghiêm ngặt:

    • Tự động khóa điều kiện tham gia nếu Điểm uy tín $< 80$ điểm.
    • Trừ trực tiếp $5$ điểm uy tín khi người dùng tự ý hủy đơn trúng đấu giá hoặc từ chối nhận hàng.
    • Ràng buộc số dư ví thực tế $\ge$ giá trị đấu giá, triệt tiêu hoàn toàn tình trạng đặt giá ảo phá hoại phiên.

  3. Mô hình tích hợp MoMo All-in-One liền mạch: Hiện thực hóa luồng thanh toán qua mã QR động (Dynamic QR Code) hiển thị trực tiếp trên giao diện Desktop kết hợp xử lý bất đồng bộ qua IPN URL. Giao dịch được xác nhận trong vòng chưa đầy $2$ giây mà không cần người quản trị duyệt thủ công.

Ứng dụng thực tế và triển khai

Chiến lược đóng gói và triển khai

Hệ thống được đóng gói thành các Docker Container độc lập và quản lý thông qua Docker Swarm / Docker Compose, cho phép mở rộng nhanh chóng (Horizontal Pod Scaling):

version: '3.8'

services:
  api-gateway:
    image: auction/api-gateway:v1.0.0
    ports:
      - "8080:8080"
    deploy:
      replicas: 2
      restart_policy:
        condition: on-failure

  auction-service:
    image: auction/auction-svc:v1.0.0
    deploy:
      replicas: 4
      resources:
        limits:
          cpus: '0.50'
          memory: 512M
    environment:
      - DB_HOST=mysql-cluster
      - GRPC_PORT=50051

  payment-service:
    image: auction/payment-svc:v1.0.0
    deploy:
      replicas: 2
    environment:
      - MOMO_PARTNER_CODE=MOMO_TEST
      - MOMO_ENDPOINT=https://test-payment.momo.vn/v2/gateway/api/create

Phân tích hiệu quả kinh tế và Khả năng ứng dụng

  • Đối tượng triển khai: Các doanh nghiệp bán lẻ đồ xa xỉ, sàn ký gửi đồ cổ/sưu tầm, các đơn vị đấu giá tài sản thanh lý hoặc tổ chức thiện nguyện gây quỹ.
  • Tối ưu hóa chi phí vận hành: Việc sử dụng Golang với mức tiêu thụ tài nguyên RAM/CPU thấp giúp giảm hơn $40%$ chi phí thuê máy chủ cloud (AWS EC2 / Google Cloud Compute Engine) so với các backend viết bằng Java Spring Boot hoặc Node.js ở cùng mức tải.
  • Thời gian hoàn vốn (ROI): Nhờ cơ chế tự động hóa từ đấu giá đến thanh toán và kiểm soát bùng hàng, doanh nghiệp có thể cắt giảm $70%$ nhân sự vận hành kiểm duyệt đơn hàng, dự kiến đạt điểm hòa vốn sau 6–9 tháng vận hành thương mại.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật hiện tại

  • Hệ thống vẫn đang sử dụng chung một cụm cơ sở dữ liệu MySQL tập trung (Shared Database Pattern), chưa phân tách hoàn toàn Database-per-Service do giới hạn hạ tầng thử nghiệm.
  • Chưa tích hợp cơ chế WebSockets để đẩy thông báo theo thời gian thực xuống Client (hiện tại Client đang sử dụng polling hoặc stream gRPC phía gateway).
  • Giao diện web được tối ưu hóa tốt nhất trên màn hình máy tính Full HD 1920x1080, chưa đạt mức hoàn hảo trên các thiết bị màn hình nhỏ (Mobile Responsive).

Hướng phát triển trong tương lai

  1. Phân rã Database hoàn chỉnh: Triển khai mô hình Database-per-Service kết hợp Saga Pattern hoặc Apache Kafka để quản lý Distributed Transactions giữa Order Service và Payment Service.
  2. Cơ chế Chống bắn tỉa giá (Sniper Bidding Prevention): Tự động gia hạn thêm 2 phút nếu có lượt đặt giá mới xuất hiện trong 30 giây cuối cùng của phiên đấu giá.
  3. Phát triển Mobile App đa nền tảng: Ứng dụng React Native hoặc Flutter nhằm tận dụng DeepLink trực tiếp vào ứng dụng MoMo trên điện thoại.
  4. Ứng dụng AI/Machine Learning: Phân tích hành vi để tự động phát hiện các tài khoản gian lận thông thầu (Shill Bidding Detection).

Đối tượng hưởng lợi

                   +-----------------------------------------------+
                   |          GIÁ TRỊ CHO CÁC BÊN LIÊN QUAN        |
                   +-----------------------------------------------+
                     /             |              |             \
                    /              |              |              \
                   v               v              v               v
            [Sinh viên]      [Lập trình viên] [Doanh nghiệp]  [Nhà nghiên cứu]
            Tài liệu tham     Mẫu thiết kế     Giải pháp TMĐT  Cơ sở thực nghiệm
            khảo kiến trúc    Microservice     đấu giá giảm    Microservices &
            Microservices     Golang + gRPC    tỷ lệ bùng hàng Fintech VN
  • Sinh viên & Học viên: Cung cấp tài liệu tham khảo toàn diện từ phân tích Use Case, mô hình hóa FDD đến triển khai thực tế kiến trúc Microservice với Golang và ReactJS.
  • Lập trình viên (Developers): Nắm vững cách ứng dụng gRPC, xử lý goroutine mutex locking để giải quyết bài toán concurrency và tích hợp cổng thanh toán MoMo chuẩn PCI DSS.
  • Doanh nghiệp TMĐT: Sở hữu giải pháp công nghệ hoàn chỉnh giúp đa dạng hóa hình thức bán hàng, tối ưu hóa giá trị thanh lý sản phẩm và giảm thiểu thiệt hại do bùng hàng.
  • Nhà nghiên cứu học thuật: Cung cấp dữ liệu thực nghiệm về độ trễ, khả năng chịu tải của gRPC so với RESTful API trong môi trường giao dịch trực tuyến thời gian thực.

Câu hỏi thường gặp

1. Yêu cầu phần cứng và môi trường tối thiểu để triển khai hệ thống là gì?

Hệ thống yêu cầu máy chủ chạy hệ điều hành Linux (Ubuntu 20.04 LTS trở lên), tối thiểu 2 vCPU, 4GB RAM và 20GB ổ cứng SSD có cài đặt Docker Engine và Docker Compose. Đối với môi trường phát triển cục bộ, cần cài đặt Golang v1.19+, Node.js v16+, MySQL Server v8.0+.

2. Hệ thống giải quyết bài toán Race Condition khi nhiều người cùng bấm đặt giá như thế nào?

Dịch vụ Auction Engine sử dụng cơ chế sync.RWMutex trong Golang kết hợp với Transaction Isolation cấp độ InnoDB của MySQL. Khi có yêu cầu đặt giá, Write Lock được kích hoạt độc quyền trong bộ nhớ cho phiên đấu giá đó để kiểm tra bước giá và gán người giữ giá cao nhất trước khi ghi nhận xuống cơ sở dữ liệu.

3. Quy trình thanh toán MoMo xử lý trường hợp mất kết nối mạng như thế nào?

Hệ thống sử dụng cơ chế xác thực bất đồng bộ IPN (Instant Payment Notification). Khi khách hàng quét mã QR thành công, cổng thanh toán MoMo sẽ liên tục gửi các gói tin Webhook có kèm chữ ký HMAC-SHA256 đến endpoint máy chủ của hệ thống cho đến khi nhận được phản hồi HTTP 200 OK. Do đó, ngay cả khi người dùng vô tình đóng trình duyệt, trạng thái đơn hàng vẫn được cập nhật chính xác.

4. Chi phí duy trì và khả năng mở rộng (Scalability) của hệ thống ra sao?

Nhờ kiến trúc Microservice đóng gói qua Docker, hệ thống có thể mở rộng riêng lẻ Auction Service hoặc Payment Service khi vào giờ cao điểm mà không cần nâng cấp toàn bộ hệ thống. Chi phí vận hành hạ tầng đám mây ước tính chỉ từ $30–$50/tháng cho quy mô 10,000 phiên đấu giá/tháng.

5. Người dùng có điểm uy tín thấp có thể phục hồi điểm để tiếp tục tham gia đấu giá không?

Có. Điểm uy tín ban đầu là 100 điểm. Mỗi lần vi phạm (hủy đơn, không nhận hàng) sẽ bị trừ 5 điểm. Người dùng có thể phục hồi điểm bằng cách hoàn tất thành công các đơn hàng thông thường hoặc nạp tiền và duy trì hoạt động mua bán minh bạch trên hệ thống theo chu kỳ đánh giá của quản trị viên.

Kết luận

Khóa luận tốt nghiệp "Phát Triển Hệ Thống Đấu Giá Trực Tuyến Tích Hợp Ví MoMo Dựa Trên Kiến Trúc Microservice" của sinh viên Lê Đoàn đã giải quyết trọn vẹn cả ba khía cạnh: Nghiệp vụ thực tiễn, Nền tảng pháp lý và Kiến trúc công nghệ hiện đại. Việc kết hợp sức mạnh xử lý đồng thời của Golang, hiệu năng truyền tải vượt trội của gRPC cùng hệ thống bảo mật thanh toán MoMo đã tạo nên một giải pháp TMĐT đấu giá trực tuyến ổn định, minh bạch và có tính ứng dụng thương mại cao.

Hệ thống là minh chứng rõ nét cho xu hướng chuyển dịch từ kiến trúc Monolithic cồng kềnh sang Microservices linh hoạt trong phát triển phần mềm doanh nghiệp, mở ra hướng đi bền vững cho các nền tảng thương mại điện tử thế hệ mới tại Việt Nam.