Multi-Location Restaurant Ordering Platform

Selected production stories

1. Story 01 · Payments

   Confirmed

   Customers were charged, then told their order failed

   Problem

   On the new-card checkout path the payment and order went through, but the app's final confirmation call sometimes failed. Customers believed the order had failed, and some ordered again.

   My contribution

   I traced it to the managed Redis scripting engine silently dropping a null field from the saved checkout session, fixed the read to treat a missing value as empty, verified it by replaying the failed call on the test environment, and rebuilt each reported customer's session from server logs to separate our bug from a bank decline and a deliberate re-order.

   Verified result

   Roughly 3 in 100 new-card checkouts had hit the error while it was live. No recurrences in the first two days after release, and the store received a per-customer breakdown.

   Proof boundary

   The null field came from one of my own earlier changes about a month before. The fix does not reverse earlier double payments; refunds were a support decision.

2. Story 02 · Data integrity

   Confirmed

   Order history showed empty for thousands of customers

   Problem

   Signed-in customers who had ordered on the brand's website saw an empty order history in the app. The list required two account identifiers, and website orders carried only one.

   My contribution

   I proved the cause on production data and changed the history to include website orders linked to the account, view-only. Review caught two dangers I fixed first: a case-insensitive email match that treated underscore and percent as wildcards and could match other people's accounts, and orders stored twice after a cancellation.

   Verified result

   Thousands of customers went from an empty history to seeing their orders. Running the new code against production data showed zero duplicates and no regressions before release.

   Proof boundary

   A website guest order placed with a registered customer's email also appears in that customer's history. Twelve lower-priority review findings were deferred.

3. Story 03 · Reliability

   Implementation confirmed

   Every signed-in feature failed until the server was restarted

   Problem

   Twice in one afternoon, every signed-in request returned errors for a few minutes and the menu failed too. A manual restart fixed it instantly both times.

   My contribution

   I used the restart clue to rule out the managed Redis itself, found the server's single long-lived Redis connection had no keepalive or reconnect strategy and was left half-open when idle connections were dropped, and built the fix: reconnect with backoff, keepalive pings, readiness based on ready rather than open, and fail-fast reads.

   Verified result

   The self-healing client is in production.

   Proof boundary

   Say the connection was made self-healing, not that outages were eliminated; recurrence data after the fix was not recorded.

4. Story 04 · Integrations

   Confirmed

   Order updates never arrived from the ordering provider

   Problem

   In launch week, production orders stayed at received forever, and item-availability and menu-change events never arrived.

   My contribution

   I proved nothing was arriving at all: the handler rejects bad signatures before storing anything, so an empty event table plus zero signature failures meant zero deliveries. I confirmed our endpoint was ready, traced the gap to a webhook subscription never configured in the provider's dashboard, and wrote the exact setup: destination URL, shared secret and event list.

   Verified result

   Once the subscription was configured, production received order updates from every channel.

   Proof boundary

   The fix was provider-side configuration, not code.

5. Story 05 · Systems integration

   Core integration confirmed

   Connected an external POS catalog and ordering workflow

   Problem

   The platform needed to import categories, modifiers, products, prices, location context, and nutrition data, then forward customer orders and process provider status updates.

   My contribution

   I implemented the catalog import and outbound-order path, aligned the provider SDK and data contracts, added pricing, location, and nutrition handling, and built the webhook-to-internal-status update path.

   Verified result

   A test order reached the provider dashboard, import fixes were deployed and acknowledged, and relevant deployment checks passed for the core flow.

   Proof boundary

   The complete status-to-notification loop was not independently verified; image import and broader security hardening are not claimed, and scheduling UI was shared work.