Inventory Sync Logic for Supplier Restaurants

Overview

Inventory synchronization ensures restaurant availability is up-to-date for Tablecheck and SevenRooms suppliers. Syncs are triggered both on a schedule and by reservation events, with robust error handling, supplier-specific rate limits, and fallback strategies.

Scheduler Details

• Runs 4 times daily:
  • 12 AM, 12 PM, 4 PM, 8 PM (Bangkok time)
• Workers:
  • Tablecheck: Vendors::Tablecheck::RestaurantsInventorySyncSchedulerWorker
  • SevenRooms: Vendors::SevenRooms::RestaurantsInventorySyncSchedulerWorker
• Config Example:
  • tablecheck_restaurants_inventory_sync_scheduler_worker:
  •   cron: "0 17,5,9,13 * * *" # 12 AM, 12 PM, 4 PM, 8 PM Bangkok time
  •   class: "Vendors::Tablecheck::RestaurantsInventorySyncSchedulerWorker"
  • seven_rooms_restaurants_inventory_sync_scheduler_worker:
  •   cron: "0 17,5,9,13 * * *" # 12 AM, 12 PM, 4 PM, 8 PM Bangkok time
  •   class: "Vendors::SevenRooms::RestaurantsInventorySyncSchedulerWorker"

Supplier Config & Limits

• Party size fallback: Up to 5 party sizes are tried per restaurant to maximize available timeslots.
• Cooldown: Minimum 10 minutes between reservation-triggered syncs for the same restaurant/date.

Party Size Array Calculation

Logic

• For each inventory sync, the system calculates a descending array of party sizes.
• Example calculation:
  • If largest_table = 10, min_seat = 2:
    • Candidates: [10, 10, 6, 4, 2]
    • Final array (unique, descending): [10, 6, 4, 2]
• The system tries each party size in order, fetching available timeslots and tracking which are still missing.
• Smaller party sizes are used as fallback for missing timeslots.

QA Checklist

• Test with restaurants having different largest_table and min_seat values.
• Confirm the party size array is calculated correctly and used in fallback logic.
• Validate that missing timeslots are retried with smaller party sizes.
• Check logs for correct reporting of party size attempts and fallback.

Trigger Types

Scheduled

• Runs for all active restaurants at set times.
• Syncs full, partial, or quick inventory depending on business rules.

Reservation-triggered

• On reservation rejection (inventory mismatch): sync if last sync is stale (cooldown applies).
• On new reservation: always sync immediately (no cooldown).

QA Checklist

• Validate scheduled syncs run at correct times and update all restaurants.
• Test reservation-triggered syncs for both trigger types and cooldown logic.
• Confirm only the affected restaurant and date are refreshed.

Sync Logic

1. Party Size Calculation:
   • System calculates descending array of party sizes.
   • Tries each size in order, only retrying missing timeslots with smaller sizes.
2. Batching & Rate Limiting:
   • Restaurants are processed in batches, with delays to respect supplier API limits.
3. Error Handling:
   • All errors (API, rate limit, DB deadlock) are reported to APM and logged for OpenSearch.
4. Notifications:
   • Staff notified for credit card required timeslots (SevenRooms) and zero inventory scenarios.
5. Data Integrity:
   • Old inventory records are deleted before import.
   • Cache is invalidated and HH-Search is updated after sync.

Monitoring & Troubleshooting

• Logs:
  • All sync actions, errors, and notifications are logged in OpenSearch (search by restaurant_id, date, supplier).
• APM:
  • ElasticAPM traces all sync operations, including spans for API calls, DB operations, and business logic.
• Notifications:
  • Staff receive emails for credit card required and zero inventory events.

QA Testing Guide

1. Scheduled Syncs

• Verify jobs run at the scheduled times and process all active restaurants.
• Check that batch sizes and delays match supplier rate limits.
• Confirm that inventory is updated for all restaurants and days as expected.

2. Reservation-Triggered Syncs

• Simulate reservation rejection due to inventory mismatch and verify that sync is triggered (with cooldown).
• Create new reservations and confirm immediate inventory sync (no cooldown).
• Check that only the affected restaurant and date are refreshed.

3. Party Size Fallback

• Test with restaurants having different largest table and min_seat values.
• Ensure the party size array is calculated and used correctly.
• Validate that missing timeslots are retried with smaller party sizes.

4. Error Handling & Notifications

• Simulate API failures, rate limits, and DB deadlocks; confirm errors are reported to APM and logged.
• Test scenarios where SevenRooms requires a credit card and verify notification emails are sent.
• Confirm zero-inventory notifications are sent when appropriate.

5. Data Integrity

• After sync, check that inventory records are correct in the database.
• Validate that cache is invalidated and HH-Search is updated.