Food Delivery Application and Taxi service Application
We built the Food Delivery Platform as an event-driven system with three independently deployable services sitting behind a single API gateway, rather than one monolithic backend. The Order Service, Dispatch Service, and Restaurant Service each own their own responsibility and can be scaled, deployed, and debugged independently — an order-intake spike that hammers the Order Service doesn't degrade active delivery tracking running through the Dispatch Service.
Order intake writes go straight to PostgreSQL and simultaneously push onto a Redis queue that the Dispatch Service consumes — so a burst of incoming orders gets buffered and processed in order, rather than each request racing to write and match a driver synchronously. Live order-tracking state (where's my food) is cached in Redis rather than hitting Postgres on every poll from the consumer app, which is what keeps tracking responsive even during peak load. Restaurant onboarding runs through its own service with a self-serve flow, so new restaurants go live without a developer touching the database.