F&B · POS · Serverless function · Event-driven design
Problem Context
In high-volume F&B environments, order state changes (received → prepared → ready) must be
communicated reliably to both customers and staff. The challenge was to design an integration that remains
reliable under retries, prevents duplicate processing, and continues operating even when downstream
messaging is slow or unavailable.
Key Requirements & Constraints
- At-least-once delivery from POS systems (retries are expected).
- Idempotent processing to prevent duplicate orders and customer records.
- Support multiple order event types (received / ready) without duplicating logic.
- Fast acknowledgement to POS to avoid blocking order flow.
- Asynchronous notifications to isolate messaging failures from ingestion.
- Fallback communication for degraded scenarios.
- Clear separation between client systems and platform responsibilities.
Architecture Overview
The architecture is designed around a thin ingestion layer and event-driven processing,
ensuring reliability without introducing unnecessary operational complexity.
- Customer places an order via Kiosk / POS.
- POS sends order events to a webhook ingestion endpoint.
- The integration layer validates, deduplicates, and normalises events.
- The system creates/updates customer records and creates order records.
- Customer notifications are delivered asynchronously.
- Order-ready events follow the same pipeline.
- SMS fallback is used when digital delivery fails.
The system treats every inbound event as potentially duplicated and every downstream dependency as potentially slow or unavailable.
Key Design Decisions & Trade-offs
1) Retry-Safe Webhook Ingestion
POS systems retry when acknowledgements are delayed. I designed the webhook path to be
fully idempotent, allowing safe retries without duplicating orders.
- 4xx responses for invalid payloads (do not retry).
- 5xx responses for transient failures (retry with backoff).
- Idempotency key based on a stable order identifier to prevent double-processing.
2) Explicit Order Event Semantics
Order lifecycle events are explicitly classified (e.g., received vs ready) so a single
pipeline can support multiple event types without duplicated logic. This simplifies extension to future states.
3) Asynchronous Notifications
Notifications are treated as side effects, not part of the core ingestion transaction. This prevents
messaging failures from blocking order processing and improves response time to the POS.
4) Customer Identity
Customer records are created/updated using an internal UUID, decoupling internal identity from external
identifiers and supporting clean lifecycle management across retries and channels.
5) Operational Fallback Path
In degraded scenarios, the system provides a fallback communication path (e.g., SMS) to ensure store
operations and customer communications continue during provider outages.
Security & Reliability Considerations
- HMAC signature validation on inbound requests.
- Idempotency checks for all order events.
- Clear sync vs async boundaries to reduce blast radius.
- Explicit failure handling with meaningful status codes.
- Fallback communication for degraded scenarios.
Outcome & Impact
- Reliable ingestion of POS events under retry conditions.
- No duplicate orders or customer records.
- Improved customer notification consistency.
- Reduced operational risk during peak hours.
- Reusable architecture pattern across vendors and POS systems.
What I’d Improve Next
- Introduce a queue/event bus between ingestion and processing for higher scale and buffering.
- Add richer observability around event latency, retries, and failure rates.
- Extend notification channels without impacting ingestion logic.
Why This Case Study Matters
This project demonstrates real-world integration design, failure-aware architecture, and
event-driven thinking—balancing technical decisions with operational and business outcomes.
