The challenge
Subscription meal delivery looks simple until the edge cases arrive: concurrent order calculations, recurring wallet transactions, meal replacement rules and customers changing dietary schedules at the same moment the kitchen list is being generated.
The requirement was 100% consistency for financial and delivery data, because a wrong balance or a missing meal is immediately visible to a customer.
How I approached it
- 01
A modular service layer with strict transactions
Business rules live in Laravel services, not controllers. Anything that touches money or a delivery slot runs inside a database transaction.
- 02
Idempotent wallet ledger
Recurring billing and refund adjustments go through wallet logic designed so a retried job or request can't apply the same movement twice.
- 03
Repository patterns for user state
Reads and writes of subscriber state are centralized, which made concurrency bugs around dietary preferences and time-slot assignment possible to isolate and fix.
- 04
Optimized batch generation
Daily subscriber meal lists are produced by tuned MySQL queries and a scheduled job instead of per-user loops, keeping the nightly run fast as the subscriber count grows.
What I built
- Designed relational schemas for users, plans, orders, wallet transactions and delivery time slots.
- Implemented the RESTful endpoints consumed by mobile apps and web frontends.
- Built idempotent wallet transaction logic for recurring subscription billing and refund adjustments.
- Optimized query performance and the daily cron processing for subscriber meal allocation.
- Fixed production concurrency bugs around dietary preference updates and time-slot assignment.
What this project demonstrates
- Wallet and billing logic that holds up under retries
- Debugging real concurrency issues in production
- Cron and queue design for daily operational jobs
