เป็นเรื่องง่ายมากเพียงแตะปุ่มบนโทรศัพท์มือถือของเรา รถแท็กซี่ก็พร้อมให้บริการภายในไม่กี่นาทีทุกที่ทุกเวลาที่เราต้องการ
Uber/Ola /Lyft… การใช้แอปพลิเคชันเหล่านี้และรับบริการขนส่งที่ไม่ยุ่งยากนั้นง่ายมาก แต่ การสร้างแอปพลิเคชันขนาดยักษ์เหล่านี้ก็เป็นเรื่องง่ายเช่นกัน ซึ่งมีวิศวกรซอฟต์แวร์หลายร้อยคนทำงานเกี่ยวกับแอปพลิเคชันเหล่านี้มานานนับทศวรรษ …? ไม่อย่างแน่นอน. ระบบเหล่านี้มีสถาปัตยกรรมที่ซับซ้อนกว่ามาก และมีส่วนประกอบมากมายที่รวมเข้าด้วยกันภายในเพื่อให้บริการขี่ทั่วโลก มาหารือกัน…

สถาปัตยกรรมระบบ Uber

เราทุกคนคุ้นเคยกับบริการของ Uber ผู้ใช้สามารถเรียกรถผ่านแอปพลิเคชัน และภายในไม่กี่นาที คนขับก็มาถึงสถานที่ใกล้เคียงเพื่อพาพวกเขาไปยังจุดหมายปลายทาง ก่อนหน้านี้ Uber สร้างขึ้นจากโมเดลสถาปัตยกรรมซอฟต์แวร์ "เสาหิน" มีบริการแบ็กเอนด์ บริการฟรอนต์เอนด์ และฐานข้อมูลเดียว พวกเขาใช้ Python และเฟรมเวิร์กของมันและ SQLAlchemy เป็นเลเยอร์ ORM ในฐานข้อมูล สถาปัตยกรรมนี้ใช้ได้ดีสำหรับการเดินทางจำนวนไม่มากในบางเมือง แต่เมื่อบริการเริ่มขยายในเมืองอื่นๆ ทีมงาน Uber ก็เริ่มประสบปัญหากับแอปพลิเคชัน หลังจากปี 2014 ทีมงาน Uber ตัดสินใจเปลี่ยนมาใช้ "สถาปัตยกรรมที่มุ่งเน้นบริการ" และตอนนี้ Uber ก็จัดการเรื่องการส่งอาหารและขนส่งสินค้าด้วย

1. พูดคุยเกี่ยวกับความท้าทาย

งานหลักอย่างหนึ่งในบริการ Uber คือการจับคู่ผู้โดยสารกับรถแท็กซี่ ซึ่งหมายความว่าเราต้องการบริการที่แตกต่างกันสองอย่างในสถาปัตยกรรมของเรา กล่าวคือ

  • บริการจัดหา (สำหรับรถแท็กซี่)
  • บริการความต้องการ (สำหรับผู้ขับขี่)

Uber มีระบบการจัดส่ง (การเพิ่มประสิทธิภาพการจัดส่ง/DISCO) ในสถาปัตยกรรมเพื่อให้ตรงกับอุปทานกับความต้องการ ระบบจัดส่งนี้ใช้โทรศัพท์มือถือและมีหน้าที่รับผิดชอบในการจับคู่ผู้ขับขี่กับผู้ขับขี่ (อุปทานตามความต้องการ)

2. ระบบจัดส่งทำงานอย่างไร?

DISCO ต้องมีเป้าหมายเหล่านี้…

  • ลดการขับรถเป็นพิเศษ
  • เวลารอขั้นต่ำ
  • การทางพิเศษแห่งประเทศไทยโดยรวมขั้นต่ำ

ระบบจัดส่งทำงานได้อย่างสมบูรณ์บนแผนที่และข้อมูลตำแหน่ง/GPS ดังนั้นสิ่งแรกที่สำคัญคือการสร้างแบบจำลองแผนที่และข้อมูลตำแหน่งของเรา

  • โลกมีรูปร่างเป็นทรงกลม ดังนั้นจึงเป็นการยากที่จะสรุปและประมาณโดยใช้ละติจูดและลองจิจูด เพื่อแก้ไขปัญหานี้ Uber จึงใช้ไลบรารี Google S2 ไลบรารีนี้จะแบ่งข้อมูลแผนที่ออกเป็นเซลล์เล็กๆ (เช่น 3 กม.) และให้รหัสเฉพาะแก่แต่ละเซลล์ นี่เป็นวิธีง่ายๆ ในการกระจายข้อมูลในระบบแบบกระจายและจัดเก็บข้อมูลได้อย่างง่ายดาย
  • ไลบรารี S2 ให้การครอบคลุมรูปร่างใดๆ ที่กำหนดได้อย่างง่ายดาย สมมติว่าคุณต้องการหาสิ่งของที่มีอยู่ทั้งหมดภายในรัศมี 3 กม. ของเมือง การใช้ไลบรารี S2 คุณสามารถวาดวงกลมรัศมี 3 กม. และจะกรองเซลล์ทั้งหมดที่มี ID ที่อยู่ในวงกลมนั้นออก วิธีนี้ทำให้คุณสามารถจับคู่ผู้ขับขี่กับผู้ขับขี่ได้อย่างง่ายดาย และคุณสามารถค้นหาจำนวนรถยนต์ (อุปทาน) ที่มีจำหน่ายในภูมิภาคใดภูมิภาคหนึ่งได้อย่างง่ายดาย

3. บริการจัดหาและทำงานอย่างไร?

  • ในกรณีของเรา รถแท็กซี่คือบริการจัดหาสินค้า และจะมีการติดตามโดยตำแหน่งทางภูมิศาสตร์ (ละติจูดและลองจิจูด) ห้องโดยสารที่ใช้งานอยู่ทั้งหมดจะส่งตำแหน่งไปยังเซิร์ฟเวอร์ทุกๆ 4 วินาทีผ่านไฟร์วอลล์แอปพลิเคชันเว็บและโหลดบาลานเซอร์ ตำแหน่ง GPS ที่แม่นยำจะถูกส่งไปยังศูนย์ข้อมูลผ่าน Rest API ของ Kafka เมื่อผ่านโหลดบาลานเซอร์แล้ว ที่นี่เราใช้ Apache Kafka เป็นศูนย์กลางข้อมูล
  • เมื่อ Kafka อัปเดตตำแหน่งล่าสุดแล้ว ตำแหน่งนั้นจะค่อยๆ ผ่านไปยังหน่วยความจำหลักของบันทึกของผู้ปฏิบัติงานตามลำดับ
  • นอกจากนี้ สำเนาของตำแหน่ง (เครื่องสถานะ/ตำแหน่งล่าสุดของรถแท็กซี่) จะถูกส่งไปยังฐานข้อมูลและไปยังการเพิ่มประสิทธิภาพการจัดส่งเพื่อให้ตำแหน่งล่าสุดอัปเดตอยู่เสมอ
  • นอกจากนี้เรายังต้องติดตามสิ่งต่างๆ อีกสองสามอย่าง เช่น จำนวนที่นั่ง ที่นั่งในรถยนต์สำหรับเด็ก ประเภทของยานพาหนะ สามารถใส่รถเข็นได้ และการจัดสรร (เช่น รถแท็กซี่อาจมีสี่ที่นั่ง แต่มี 2 ที่นั่งในนั้น .)

4. บริการความต้องการและมันทำงานอย่างไร?

  • บริการความต้องการได้รับคำขอของรถแท็กซี่ผ่านเว็บซ็อกเก็ตและติดตามตำแหน่ง GPS ของผู้ใช้ นอกจากนี้ยังได้รับข้อกำหนดประเภทต่างๆ เช่น จำนวนที่นั่ง ประเภทรถ หรือรถพูล
  • ความต้องการระบุตำแหน่ง (รหัสเซลล์) และความต้องการของผู้ใช้ในการจัดหาและร้องขอรถแท็กซี่

5. ระบบการจัดส่งจะจับคู่ผู้ขับขี่กับผู้ขับขี่อย่างไร

  • เราได้พูดคุยกันว่า DISCO แบ่งแผนที่ออกเป็นเซลล์เล็กๆ ด้วยรหัสเฉพาะ ID นี้ใช้เป็นคีย์ชาร์ดดิ้งใน DISCO เมื่ออุปทานได้รับการร้องขอจากความต้องการ ตำแหน่งจะได้รับการอัปเดตโดยใช้รหัสเซลล์เป็นคีย์ชาร์ด ความรับผิดชอบของเซลล์เล็กๆ เหล่านี้จะถูกแบ่งออกเป็นเซิร์ฟเวอร์ที่แตกต่างกันซึ่งอยู่ในหลายภูมิภาค (การแฮชที่สอดคล้องกัน) ตัวอย่างเช่น เราสามารถจัดสรรความรับผิดชอบของเซลล์เล็กๆ 12 เซลล์ให้กับเซิร์ฟเวอร์ที่แตกต่างกัน 6 เซลล์ (2 เซลล์สำหรับแต่ละเซิร์ฟเวอร์) ซึ่งอยู่ใน 6 ภูมิภาคที่แตกต่างกัน

  • อุปทานส่งคำขอไปยังเซิร์ฟเวอร์เฉพาะตามข้อมูลตำแหน่ง GPS หลังจากนั้น ระบบจะดึงวงกลมและกรองห้องโดยสารใกล้เคียงทั้งหมดที่ตรงกับความต้องการของผู้ขับขี่ออก
  • หลังจากนั้น รายชื่อรถแท็กซี่จะถูกส่งไปยัง ETA เพื่อคำนวณระยะห่างระหว่างผู้ขับขี่และรถแท็กซี่ ไม่ใช่ตามภูมิศาสตร์ แต่ตามระบบถนน
  • จากนั้น ETA ที่เรียงลำดับแล้วจะถูกส่งกลับไปยังระบบจ่ายเพื่อเสนอให้กับคนขับ

หากเราจำเป็นต้องจัดการกับการรับส่งข้อมูลสำหรับเมืองที่เพิ่งเพิ่มเข้าไป เราก็สามารถเพิ่มจำนวนเซิร์ฟเวอร์และจัดสรรความรับผิดชอบของ ID เซลล์ของเมืองที่เพิ่มใหม่ให้กับเซิร์ฟเวอร์เหล่านี้ได้

6. จะปรับขนาดระบบจัดส่งได้อย่างไร?

  • ระบบการจัดส่ง (รวมถึงอุปสงค์ อุปสงค์ และซ็อกเก็ตเว็บ) สร้างขึ้นบน NodeJS NodeJS เป็นเฟรมเวิร์กแบบอะซิงโครนัสและอิงตามเหตุการณ์ที่ช่วยให้คุณสามารถส่งและรับข้อความผ่าน WebSockets ได้ทุกเมื่อที่คุณต้องการ
  • Uber ใช้ ringpop แบบโอเพ่นซอร์สเพื่อทำให้แอปพลิเคชันทำงานร่วมกันและปรับขนาดได้สำหรับการรับส่งข้อมูลจำนวนมาก Ring pop มีสามส่วนหลักๆ และดำเนินการด้านล่างเพื่อปรับขนาดระบบการจัดส่ง
  1. โดยจะรักษาการแฮชที่สม่ำเสมอเพื่อมอบหมายงานให้กับผู้ปฏิบัติงาน ช่วยในการแบ่งส่วนแอปพลิเคชันในลักษณะที่สามารถปรับขนาดได้และทนทานต่อข้อผิดพลาด
  2. Ringpop ใช้ โปรโตคอล RPC (การเรียกขั้นตอนระยะไกล) เพื่อโทรจากเซิร์ฟเวอร์หนึ่งไปยังเซิร์ฟเวอร์อื่น
  3. Ringpop ยังใช้ โปรโตคอลการเป็นสมาชิก SWIM/โปรโตคอลการนินทา ที่ช่วยให้พนักงานอิสระค้นพบความรับผิดชอบของกันและกัน วิธีนี้ทำให้แต่ละเซิร์ฟเวอร์/โหนดทราบถึงความรับผิดชอบและการทำงานของโหนดอื่นๆ
  4. Ringpop ตรวจพบโหนดที่เพิ่งเพิ่มเข้าไปในคลัสเตอร์และโหนดที่ถูกลบออกจากคลัสเตอร์ โดยจะกระจายโหลดอย่างสม่ำเสมอเมื่อมีการเพิ่มหรือลบโหนด

7. Uber กำหนดภูมิภาคของแผนที่อย่างไร

ก่อนที่จะเปิดตัวการดำเนินการใหม่ในพื้นที่ใหม่ Uber ได้นำภูมิภาคใหม่ไปสู่กลุ่มเทคโนโลยีแผนที่ ในภูมิภาคแผนที่นี้ เรากำหนดภูมิภาคย่อยต่างๆ ที่มีป้ายกำกับด้วยเกรด A, B, AB และ C

เกรด A: ภูมิภาคย่อยนี้มีหน้าที่รับผิดชอบในการครอบคลุมใจกลางเมืองและพื้นที่การเดินทาง ปริมาณการใช้งาน Uber ประมาณ 90% ครอบคลุมอยู่ในภูมิภาคย่อยนี้ ดังนั้นการสร้างแผนที่คุณภาพสูงสุดสำหรับภูมิภาคย่อย A จึงเป็นสิ่งสำคัญ

เกรด B: ภูมิภาคย่อยนี้ครอบคลุมพื้นที่ชนบทและชานเมืองซึ่งมีประชากรน้อยและลูกค้า Uber เดินทางน้อย

เกรด AB: การรวมกันของภูมิภาคย่อยเกรด A และ B

เกรด C: ครอบคลุมชุดทางเดินทางหลวงที่เชื่อมต่อกับเขตแดน Uber ต่างๆ

8. Uber สร้างแผนที่อย่างไร

Uber ใช้ผู้ให้บริการแผนที่บุคคลที่สามเพื่อสร้างแผนที่ในแอปพลิเคชันของตน ก่อนหน้านี้ Uber ใช้บริการ "Mapbox" แต่ต่อมา Uber ได้เปลี่ยนมาใช้ "Google Maps API" เพื่อติดตามตำแหน่งและคำนวณ ETA

1. การครอบคลุมการติดตาม: การครอบคลุมการติดตามจะระบุส่วนของถนนที่หายไปหรือรูปทรงของถนนที่ไม่ถูกต้อง การคำนวณความครอบคลุมการติดตามจะขึ้นอยู่กับอินพุต 2 รายการ ได้แก่ ข้อมูลแผนที่ที่อยู่ระหว่างการทดสอบ และการติดตาม GPS ในอดีตของการโดยสาร Uber ทั้งหมดในช่วงเวลาหนึ่ง โดยครอบคลุมร่องรอย GPS เหล่านั้นบนแผนที่ เปรียบเทียบและจับคู่กับส่วนของถนน หากเราพบส่วนของถนนที่หายไป (ไม่มีการแสดงถนน) บนร่องรอย GPS เราจะดำเนินการแก้ไขข้อบกพร่อง

<แข็งแกร่ง>2. ความแม่นยำของจุดเข้าถึง (รับ) ที่ต้องการ: เราได้รับจุดรับในแอปพลิเคชันของเราเมื่อเราจองรถแท็กซี่ใน Uber จุดรับส่งเป็นตัวชี้วัดที่สำคัญมากใน Uber โดยเฉพาะอย่างยิ่งสำหรับสถานที่ขนาดใหญ่ เช่น สนามบิน วิทยาเขตของวิทยาลัย สนามกีฬา โรงงาน หรือบริษัท เราคำนวณระยะทางระหว่างสถานที่จริงกับจุดรับและจุดส่งทั้งหมดที่คนขับใช้

จากนั้นคำนวณระยะทางที่สั้นที่สุด (จุดรับที่ใกล้ที่สุด) และเราจะตั้งค่าหมุดไปยังตำแหน่งนั้นเป็นจุดเชื่อมต่อที่ต้องการบนแผนที่ เมื่อผู้ขับขี่ร้องขอตำแหน่งที่ระบุด้วยหมุดแผนที่ แผนที่จะนำทางผู้ขับขี่ไปยังจุดเชื่อมต่อที่ต้องการ การคำนวณจะดำเนินต่อไปด้วยสถานที่รับและส่งจริงล่าสุด เพื่อให้มั่นใจถึงความสดใหม่และความแม่นยำของจุดเข้าใช้งานที่แนะนำ Uber ใช้การเรียนรู้ของเครื่องและอัลกอริธึมต่างๆ เพื่อค้นหาจุดเชื่อมต่อที่ต้องการ

9. ETA มีการคำนวณอย่างไร?

การทางพิเศษแห่งประเทศไทยเป็นตัวชี้วัดที่สำคัญอย่างยิ่งใน Uber เนื่องจากส่งผลโดยตรงต่อการจับคู่การเดินทางและรายได้ การทางพิเศษแห่งประเทศไทยคำนวณตามระบบถนน (ไม่ใช่ทางภูมิศาสตร์) และมีหลายปัจจัยที่เกี่ยวข้องในการคำนวณการทางพิเศษแห่งประเทศไทย (เช่น การจราจรหนาแน่นหรือการก่อสร้างถนน) เมื่อผู้ขับขี่ขอรถแท็กซี่จากสถานที่ แอปไม่เพียงแต่ระบุรถแท็กซี่ว่าง/ไม่ได้ใช้งาน แต่ยังรวมถึงรถแท็กซี่ที่กำลังจะสิ้นสุดการเดินทางด้วย อาจเป็นไปได้ว่ารถแท็กซี่คันใดคันหนึ่งที่กำลังจะสิ้นสุดการเดินทางนั้นอยู่ใกล้กับความต้องการมากกว่าห้องโดยสารที่อยู่ห่างไกลจากผู้ใช้ รถยนต์ Uber จำนวนมากบนท้องถนนส่งตำแหน่ง GPS ทุกๆ 4 วินาที ดังนั้นเพื่อคาดการณ์สภาพการจราจร เราสามารถใช้ข้อมูลตำแหน่ง GPS ของแอปของคนขับได้

เราสามารถแสดงเครือข่ายถนนทั้งหมดบนกราฟเพื่อคำนวณ ETA เราสามารถใช้อัลกอริทึมจำลองของ AI หรืออัลกอริทึมของ Dijkstra แบบง่ายๆ เพื่อค้นหาเส้นทางที่ดีที่สุดในกราฟนี้ ในกราฟนั้น จุดต่างๆ แสดงถึงทางแยก (รถแท็กซี่ที่มีให้บริการ) และขอบแสดงถึงส่วนของถนน เราแสดงระยะทางของส่วนของถนนหรือระยะเวลาในการเดินทางผ่านน้ำหนักของขอบถนน นอกจากนี้เรายังเป็นตัวแทนและสร้างโมเดลปัจจัยเพิ่มเติมบางอย่างในกราฟของเรา เช่น ถนนเดินรถทางเดียว ค่าใช้จ่ายในการเลี้ยว ข้อจำกัดในการเลี้ยว และการจำกัดความเร็ว

เมื่อตัดสินใจโครงสร้างข้อมูลแล้ว เราจะค้นหาเส้นทางที่ดีที่สุดได้โดยใช้ "อัลกอริธึมการค้นหาของ Dijkstra" ซึ่งเป็นหนึ่งในอัลกอริธึมการกำหนดเส้นทางที่ทันสมัยที่สุดในปัจจุบัน เพื่อประสิทธิภาพที่เร็วขึ้น เราจำเป็นต้องใช้ OSRM (Open Source Routing Machine) ซึ่งอิงตาม ลำดับชั้นการย่อ ระบบที่อิงตามลำดับชั้นการย่อจะใช้เวลาเพียงไม่กี่มิลลิวินาทีในการคำนวณเส้นทาง โดยการประมวลผลกราฟเส้นทางล่วงหน้า

10. ฐานข้อมูล

Uber ต้องพิจารณาข้อกำหนดบางประการสำหรับฐานข้อมูลเพื่อประสบการณ์ที่ดีขึ้นของลูกค้า ข้อกำหนดเหล่านี้คือ...

  • ฐานข้อมูลควรปรับขนาดได้ในแนวนอน คุณสามารถเพิ่มความจุเชิงเส้นได้โดยการเพิ่มเซิร์ฟเวอร์
  • ควรสามารถรองรับการอ่านและเขียนได้จำนวนมาก เนื่องจากรถแท็กซี่ทุกๆ 4 วินาทีจะส่งตำแหน่ง GPS และตำแหน่งนั้นจะได้รับการอัปเดตในฐานข้อมูล
  • ระบบไม่ควรให้เวลาหยุดทำงานสำหรับการดำเนินการใดๆ ควรมีความพร้อมใช้งานสูงไม่ว่าคุณจะดำเนินการใดก็ตาม (ขยายพื้นที่เก็บข้อมูล สำรองข้อมูล เมื่อมีการเพิ่มโหนดใหม่ ฯลฯ)

ก่อนหน้านี้ Uber ใช้ฐานข้อมูล RDBMS PostgreSQL แต่เนื่องจากปัญหาด้านความสามารถในการปรับขนาด Uber จึงเปลี่ยนไปใช้ฐานข้อมูลต่างๆ Uber ใช้ฐานข้อมูล NoSQL (ไม่มีสคีมา) ที่สร้างขึ้นบนฐานข้อมูล MySQL

  • Redis สำหรับทั้งแคชและการเข้าคิว บางส่วนอยู่เบื้องหลัง Twemproxy (ซึ่งให้ความสามารถในการปรับขนาดของเลเยอร์แคช) บางส่วนอยู่เบื้องหลังระบบการจัดกลุ่มแบบกำหนดเอง
  • Uber ใช้ schemaless (สร้างขึ้นภายในบริษัทบน MySQL), Riak และ Cassandra Schemaless มีไว้สำหรับการจัดเก็บข้อมูลระยะยาว Riak และ Cassandra ตอบสนองความต้องการด้านความพร้อมใช้งานสูงและมีเวลาแฝงต่ำ
  • ฐานข้อมูล MySQL
  • Uber กำลังสร้างร้านค้าคอลัมน์แบบกระจายของตนเองเพื่อจัดการอินสแตนซ์ MySQL จำนวนมาก

11. การวิเคราะห์

เพื่อเพิ่มประสิทธิภาพระบบ ลดต้นทุนการดำเนินงาน และเพื่อประสบการณ์ของลูกค้าที่ดีขึ้น Uber จะทำการรวบรวมและวิเคราะห์บันทึก Uber ใช้เครื่องมือและเฟรมเวิร์กที่แตกต่างกันสำหรับการวิเคราะห์ สำหรับการวิเคราะห์บันทึก Uber จะใช้คลัสเตอร์ Kafka หลายคลัสเตอร์ Kafka นำข้อมูลในอดีตไปพร้อมกับข้อมูลแบบเรียลไทม์ ข้อมูลจะถูกเก็บถาวรไว้ใน Hadoop ก่อนที่จะหมดอายุจาก Kafka ข้อมูลยังถูกจัดทำดัชนีไว้ในสแต็กการค้นหาแบบยืดหยุ่นสำหรับการค้นหาและการแสดงภาพ การค้นหาแบบยืดหยุ่นทำการวิเคราะห์บันทึกโดยใช้ Kibana/Graphana การวิเคราะห์บางส่วนที่ดำเนินการโดย Uber โดยใช้เครื่องมือและเฟรมเวิร์กที่แตกต่างกัน ได้แก่...

  • ติดตาม HTTP API
  • จัดการโปรไฟล์
  • รวบรวมคำติชมและการให้คะแนน
  • โปรโมชั่นและคูปอง ฯลฯ
  • การตรวจจับการฉ้อโกง
  • การฉ้อโกงการชำระเงิน
  • การละเมิดสิ่งจูงใจโดยคนขับ
  • บัญชีที่ถูกบุกรุกโดยแฮกเกอร์ Uber ใช้ข้อมูลประวัติของลูกค้าและเทคนิคการเรียนรู้ของเครื่องเพื่อแก้ไขปัญหานี้

12. วิธีจัดการกับความล้มเหลวของดาต้าเซ็นเตอร์?

ความล้มเหลวของศูนย์ข้อมูลไม่ได้เกิดขึ้นบ่อยนัก แต่ Uber ยังคงมีศูนย์ข้อมูลสำรองเพื่อให้การเดินทางเป็นไปอย่างราบรื่น ศูนย์ข้อมูลนี้มีส่วนประกอบทั้งหมด แต่ Uber จะไม่คัดลอกข้อมูลที่มีอยู่ไปยังศูนย์ข้อมูลสำรอง

แล้ว Uber จะจัดการกับความล้มเหลวของศูนย์ข้อมูลอย่างไร

จริงๆ แล้วใช้โทรศัพท์ของคนขับเป็นแหล่งข้อมูลการเดินทางเพื่อแก้ไขปัญหาความล้มเหลวของศูนย์ข้อมูล
เมื่อแอปโทรศัพท์ของคนขับสื่อสารกับระบบสั่งการหรือการเรียก API ที่เกิดขึ้นระหว่างกัน ระบบสั่งงานจะส่งสถานะสรุปที่เข้ารหัส (เพื่อติดตามข้อมูล/ข้อมูลล่าสุด) ไปยังแอปโทรศัพท์ของคนขับ ทุกครั้งที่แอปโทรศัพท์ของคนขับจะได้รับสรุปสถานะนี้ ในกรณีที่ศูนย์ข้อมูลเกิดความล้มเหลว ศูนย์ข้อมูลสำรอง (DISCO สำรอง) จะไม่ทราบอะไรเกี่ยวกับการเดินทาง จึงจะขอสถานะสรุปจากแอปโทรศัพท์ของผู้ขับขี่ และจะอัปเดตตัวเองด้วยข้อมูลสรุปสถานะที่ผู้ขับขี่ได้รับ แอพโทรศัพท์