Swiggy Celebrations

Food delivery is built around one person, one restaurant, one cart. A celebration is the opposite: many people, several restaurants, one occasion, and everything has to land at the same time. That breaks the usual model in three places at once. Ordering has to fan out across restaurants while still reading as a single order. Guests have to join and choose without being forced to create accounts first. And money has to be settled fairly between people who are not in the same room. Doing this on top of a live platform meant working inside Swiggy’s existing catalogue, address and ordering contracts rather than around them.

• Modelled a celebration as its own first-class entity rather than a cart with extras, with 11 dedicated endpoints covering creation, guest management, menu assembly and settlement. Items from different restaurants attach to the celebration, so the shared cart is a real domain object, not a UI illusion.
• Built the guest journey around invite tokens (`/invites/:token`) so a guest can open a link, browse and add their choices before any account exists. Identity is only required at the point it actually matters.
• Integrated Swiggy across 14 endpoints and two distinct catalogues — Food and Instamart — behind separate services, so a celebration can pull cooked meals and pantry items in the same flow while each upstream integration stays independently testable.
• Wired Swiggy OAuth (`/auth/swiggy/begin`) so users arrive already authenticated against their real Swiggy account, addresses and order history, instead of the app maintaining a parallel identity.
• Moved everything time-sensitive off the request path onto BullMQ queues and scheduled jobs: invite fan-out, reminders, and the coordination needed to make multi-restaurant orders converge on one delivery window. A celebration is planned days ahead, so the system had to be reliable across time, not just fast within a request.
• Isolated money handling in a dedicated crypto service and kept bill-splitting logic in the service layer rather than the controllers, so the arithmetic that decides who owes what is unit-testable in isolation.
• Added a second front door for offices (`/work`, 18 endpoints) reusing the same celebration core with a corporate catalogue, so the workplace use case did not fork the codebase.

• Officially shortlisted by Swiggy — the strongest external validation the build could get.
• 49 endpoints across 23 modules, with the shared cart, invites, corporate mode and both Swiggy catalogues each isolated behind their own service.
• A guest flow that works from a link with no signup, which is what makes group ordering actually spread.
• Corporate ordering shipped as a mode of the same system rather than a second product to maintain.