Uber-এর মতো ride-sharing সেবা ডিজাইন

লক্ষ্য: rider ride চায়; সিস্টেম কাছের ফাঁকা driver খুঁজে দেয়, trip ট্র্যাক করে এবং ভাড়া নেয়।

Requirement

• Driver ক্রমাগত location জানায়।
• Rider ride চায় এবং কয়েক সেকেন্ডে কাছের driver-এর সাথে match হয়।
• Rider ও driver-এর জন্য trip-এর লাইভ ট্র্যাকিং।
• নির্ভরযোগ্য trip state ও payment।

অনুমান

ধরুন ১০ লাখ active driver প্রতি ৪ সেকেন্ডে location পাঠায়: প্রায় ২,৫০,০০০ location update প্রতি সেকেন্ডে। এটি write-ভারী এবং data স্বল্পস্থায়ী, তাই প্রতিটি বিন্দু চিরকাল রাখতে হয় না।

Location গ্রহণ

Driver-এর অ্যাপ gateway দিয়ে একটি দ্রুত in-memory store-এ (Redis বা অনুরূপ) update পাঠায়, যেখানে প্রতি driver-এর শুধু সর্বশেষ অবস্থান থাকে। পুরোনো বিন্দু হট পথের বাইরে analytics ও trip ইতিহাসের জন্য log-এ (Kafka) যেতে পারে।

কাছের driver খোঁজা: geospatial index

সব driver স্ক্যান করা অনেক ধীর। মানচিত্রকে cell-এ ভাগ করুন:

• Geohash বা S2/H3 cell: প্রতিটি অবস্থান একটি cell ID-তে ম্যাপ হয়। Driver cell দিয়ে index করা।
• Rider-এর request তার cell ও পাশের cell-গুলো দেখে, তারপর candidate-দের দূরত্ব বা আনুমানিক পৌঁছানোর সময় দিয়ে সাজায়।

Redis সরাসরি geospatial query সমর্থন করে (GEOSEARCH), যা শুরুর ভালো জায়গা।

Matching

1. Rider ride চায় (pickup, গন্তব্য)।
2. Matching service কাছের ফাঁকা candidate driver আনে।
3. সেরা driver-কে ছোট timeout-সহ offer পাঠায়। প্রত্যাখ্যান বা উপেক্ষা হলে পরেরজনের কাছে যায়।
4. গ্রহণ করলে driver-কে lock করে যাতে দুবার assign না হয়, এবং trip তৈরি করে।

"এক driver, এক trip" নিয়ম সাবধানে সামলাতে হয়: দ্বিগুণ assign এড়াতে driver state-এ atomic operation বা lock ব্যবহার করুন।

Trip state machine

Trip যায় অবস্থার মধ্য দিয়ে: REQUESTED -> ACCEPTED -> ARRIVED -> IN_PROGRESS -> COMPLETED (বা CANCELLED)। অবস্থার বদল নির্ভরযোগ্য database-এ রাখুন এবং বদলগুলো idempotent করুন, কারণ খারাপ network-এ অ্যাপ retry করে।

লাইভ ট্র্যাকিং

Trip চলাকালে driver-এর location WebSocket বা SSE দিয়ে rider-কে push করুন। প্রতি GPS টিকে নয়, কয়েক সেকেন্ড পরপর আপডেট দিন।

ভাড়া ও payment

ভাড়া দূরত্ব, সময় ও চাহিদা থেকে। Surge pricing সেই cell-এ দাম বাড়ায় যেখানে request ফাঁকা driver-এর চেয়ে বেশি। Trip শেষে idempotency key সহ payment service দিয়ে চার্জ করুন।

Scaling

শহর বা অঞ্চল দিয়ে partition করুন। এক শহরের driver ও rider অন্য শহরের সাথে কমই মেশে, তাই sharding স্বাভাবিক।

মূল কথা: driver-এর শুধু সর্বশেষ অবস্থান memory-তে রাখুন, geo cell দিয়ে index করুন, locked offer প্রবাহে match করুন, আর trip-কে idempotent state machine হিসেবে মডেল করুন।

---

System Design সিরিজ, পর্ব ৩ (case study): 6 নম্বর (মোট 16)। আগের লেখা: YouTube-এর মতো video streaming সেবা ডিজাইন.