الطلبات متعددة القنوات: QR، نادل، وهاتف على نفس الطاولة

ليلة جمعة في إسكي شهير: خمسة أشخاص حول الطاولة. اثنان يطلبان عبر QR، واثنان عبر POS النادل، والخامس يتصل لطلب جاهز للأخذ. ثلاث قنوات، طاولة واحدة، فاتورة واحدة — و2300 طلب شهريًا تتجمع نظيفة في table_session واحدة.

جلسة واحدة، مصادر متعددة

كل طاولة تفتح table_session بعمر 60 دقيقة. QR وPOS والهاتف يتشاركون نفس session_token؛ يسجل حقل order_source المصدر.

تسوية نهاية الوردية نزلت من 40–50 دقيقة إلى 3 دقائق.

الكتابة الذرية

الطلبات المتزامنة تُحل عبر Idempotency-Key من crypto.randomUUID() وdb.batch() ذرية في D1.

• QR وPOS يكتبان بلا تصادم.
• الخادم يفرض السعر القانوني.
• Shadowban لكل مصدر بشكل مستقل.

إجابة تقنية على "Unified Orders"

عمليًا: order_source enum، مفتاح أجنبي مشترك table_session_id، وبطاقات KDS ملوّنة حسب المصدر. الهاتف أزرق، QR أخضر.

الزبائن الأكبر سنًا يفضلون النادل، ما يلتقط 18% من الاستخدام.

FAQ

كيف يلتصق طلب الهاتف بالجلسة الصحيحة؟ يختار النادل رقم الطاولة؛ إن كانت جلسة مفتوحة تُستخدم، وإلا تُفتح جديدة.

QR اثنان يضيفان نفس الصنف في نفس اللحظة؟ صفّان order_item، بطاقتان KDS — متعمد.

ماذا بعد انتهاء TTL ساعة؟ الفواتير المفتوحة محفوظة؛ cron الساعة 04:00 UTC ينظّف الجلسات المغلقة فقط.

هل وجدت هذا مفيداً؟ شاركه.