CASE 01 / ENGINEERING IN DETAIL
Restaurant Orders & Payments
An order can be processed while its notification is still waiting for a device acknowledgment.
Context and constraints
Yunxiaoer and Yunzhanggui handled restaurant orders, payments, and store notifications. After an order was processed, store printers and staff still needed to be notified. Disconnections and missing acknowledgments required a decision about retries. I was responsible for architecture setup and core development; this case focuses on orders, payments, and notification handling.
Core workflow
This diagram is a simplified view of the technical approach.
- 01 / Business entryOrders and store operations
- 02 / Order serviceCore business workflow
- 03 / Payment integrationPayment gateway connections
- 04 / Device notificationPersistent connections, push, and acknowledgments
Design decisions and implementation
Separate order workflows from payment integration
ChallengeOrders, payments, and risk controls were closely connected. Mixing their responsibilities would make changes and integration work harder to contain.
ApproachUsed the order module to coordinate the core workflow, developed the payment gateway, and worked with the risk-control module, keeping business orchestration distinct from external channel integration.
ReasoningOrder changes and payment integrations have separate implementation points. Integration checks can examine business state and channel responses independently.
Use persistent connections first, with push as a fallback
ChallengeCompleting an order did not establish whether the store or its staff had received the notification.
ApproachThe notification path consumes new-order messages through RabbitMQ, prioritizes Netty persistent connections, and uses JPush as a fallback for store printing and staff notifications.
ReasoningPersistent connections provide the immediate path and push provides a fallback. Both still need application acknowledgments to establish delivery.
Retry unconfirmed notifications with duplicate controls
ChallengeNetwork changes and device availability could leave notifications unconfirmed, while retries from multiple nodes could create duplicates.
ApproachThe notification path uses application acknowledgments to trigger limited retries for unconfirmed orders, with Redis counters restricting repeated JPush notifications across nodes.
ReasoningMissing acknowledgments can trigger limited retries, while Redis counters restrict repeated push attempts across nodes. Sending a notification still does not establish that printing finished.
What the design addresses
Combined a persistent-connection-first notification path with push fallback, application acknowledgments, and Redis counters for unconfirmed orders.
Validation focus
- Are successful order processing and confirmed device delivery represented as distinct states?
- Are retry limits and stopping conditions explicit when a device disconnects or an acknowledgment is missing?
- Are duplicate notifications controlled when multiple nodes process the same event?
My contribution
Responsible for architecture setup and core development of Yunxiaoer and Yunzhanggui. Led the order module, developed the payment gateway, and contributed to the risk-control module.