Kiến trúc Real-time của Ứng dụng Gọi xe (Uber, Grab)

Bài toán kỹ thuật Hãy tưởng tượng bạn là kỹ sư tại Uber hoặc Grab. Hệ thống của bạn phải: Nhận tọa độ GPS từ hàng triệu tài xế mỗi 4 giây. Lưu và lập chỉ mục toàn bộ vị trí này trong bộ nhớ RAM (in-memory) để truy vấn trong dưới 10ms. Khi khách gọi xe, tìm và xếp hạng tài xế phù hợp nhất trong bán kính vài km, tính thời gian đến (ETA) dựa trên giao thông thực tế, rồi gửi cuốc xe xuống điện thoại tài xế tức thì — tất cả trong vòng 2 giây. Đồng thời, liên tục tính toán giá động (surge pricing) dựa trên tỷ lệ cung-cầu tại từng khu vực, cập nhật mỗi vài giây. Đây không phải một bài toán CRUD thông thường. Đây là một trong những hệ thống phân tán phức tạp nhất thế giới. ...

Bài toán: Hàng triệu tài xế, mỗi 4 giây Grab có khoảng 5 triệu tài xế hoạt động tại Đông Nam Á. Uber có hơn 5 triệu tài xế toàn cầu. Nếu mỗi tài xế gửi tọa độ GPS mỗi 4 giây, hệ thống phải nhận: 5.000.000 tài xế ÷ 4 giây = 1.250.000 gói tin GPS / giây Đây là 1.25 triệu write operations mỗi giây — chỉ riêng cho dữ liệu vị trí, chưa tính các request khác. HTTP REST truyền thống không thể xử lý tải này hiệu quả. ...

Bài toán: Tìm kim trong đống rơm Khi bạn bấm “Đặt xe” trên Grab, hệ thống phải tìm tài xế phù hợp nhất trong bán kính vài km. Nhưng hệ thống đang theo dõi hàng triệu tài xế đồng thời. Cách tiếp cận ngây thơ — tính khoảng cách từ bạn tới mọi tài xế — là bất khả thi: Cách ngây thơ (Brute Force): SELECT * FROM drivers WHERE ST_Distance(driver_location, rider_location) < 2000 -- 2km ORDER BY ST_Distance(driver_location, rider_location) Với 5 triệu tài xế → 5 triệu phép tính khoảng cách Latency: hàng giây → Không chấp nhận được Giải pháp: Chia bản đồ thành lưới (Spatial Indexing) để thu hẹp không gian tìm kiếm từ hàng triệu xuống vài chục. ...

Tại sao cần Event Streaming? Hàng triệu sự kiện xảy ra mỗi giây trong hệ thống gọi xe: Tài xế A cập nhật tọa độ GPS. Khách hàng B mở app và đặt xe. Tài xế C nhận cuốc và bắt đầu di chuyển. Khách hàng D huỷ cuốc. Surge pricing cập nhật hệ số nhân tại khu vực Quận 1. Nếu mỗi service gọi trực tiếp lẫn nhau (synchronous), hệ thống sẽ trở nên chặt chẽ (tightly coupled) và dễ vỡ — một service chậm sẽ kéo sập cả chuỗi. Giải pháp là Event Streaming: mọi sự kiện đều được đẩy vào một “đường ống” trung tâm, và các service tự đăng ký lắng nghe những sự kiện mình cần. ...

Vấn đề: Tại sao không chỉ chọn tài xế gần nhất? Bản năng đầu tiên khi thiết kế matching: ghép mỗi khách hàng với tài xế gần nhất. Nhưng cách tiếp cận Greedy này gây tổn thất lớn ở quy mô hệ thống: Ví dụ: 3 khách (R1, R2, R3) và 3 tài xế (D1, D2, D3) Greedy Matching (tài xế gần nhất): R1 ← D1 (ETA 2 phút) ✓ R2 ← D3 (ETA 8 phút) ← D2 đã bị R1 "lấy mất" dù D2 gần R2 hơn R3 ← D2 (ETA 10 phút) ← Kết quả tệ Tổng ETA: 2 + 8 + 10 = 20 phút Optimal Matching (tối ưu toàn cục): R1 ← D2 (ETA 3 phút) R2 ← D1 (ETA 3 phút) R3 ← D3 (ETA 4 phút) Tổng ETA: 3 + 3 + 4 = 10 phút ← Tốt hơn 50%! Uber gọi bài toán này là Global Optimization — tìm cách phân công sao cho tổng ETA của toàn bộ hệ thống là nhỏ nhất, chứ không phải ETA của từng cặp riêng lẻ. ...

Tại sao cần Surge Pricing? Đêm Giao thừa, trời mưa lớn, tan ca giờ cao điểm — nhu cầu gọi xe tăng vọt nhưng số tài xế không đổi. Nếu giữ giá cố định: Khách đặt xe không được vì hết tài xế. Tài xế ở khu vực khác không có động lực di chuyển đến khu vực nóng. Hệ thống quá tải, khách chờ rất lâu. Surge Pricing (hay Dynamic Pricing) không chỉ là công cụ tăng doanh thu — nó là cơ chế cân bằng thị trường (marketplace equilibrium mechanism): ...

Bài toán: Đẩy thông báo tức thì tới hàng triệu thiết bị Khi DISCO quyết định ghép bạn với tài xế Nguyễn Văn A, hệ thống phải: Gửi cuốc xe đến đúng điện thoại của tài xế A (trong số hàng triệu điện thoại đang kết nối). Gửi trong mili-giây (không phải giây). Đảm bảo tài xế nhận được dù mạng 4G đang yếu. Đồng thời gửi vị trí tài xế ngược về app của bạn để hiển thị xe di chuyển trên bản đồ. Có hai cách tiếp cận: Polling (hỏi liên tục) và Push (đẩy chủ động). ...