Modular before distributed
A modular monolith created strong domain boundaries and one practical deployment unit while the product and team were still moving quickly.
04
Stradha
Pre-arrival dining powered by location, retrieval, and real-time coordination
NestJSAWS BedrockPostGISApp Runner
Overview
Stradha connects diners and restaurant teams before arrival. Guests can explore nearby restaurants, receive preference-aware meal recommendations, customise and place an order, then follow preparation progress. Restaurants receive the order, dietary context, and arrival timing early enough to coordinate the kitchen around the guest.
One shared timeline,
for both sides of the table.
My role at Stradha
Backend Developer · Contract
February—October 2026
Remote · Texas, US
I designed the backend, AI, and cloud systems behind the pre-arrival dining experience.
- 01
Architected a scalable NestJS and TypeScript modular monolith spanning orders, payments, restaurants, and real-time notifications.
- 02
Designed the AI virtual waitress with AWS Bedrock, Claude 3.5 Sonnet, PostgreSQL, and pgvector using retrieval-augmented generation.
- 03
Defined the AWS infrastructure around App Runner, RDS PostgreSQL with PostGIS, and S3 with CloudFront for compute, routing, and media.
- 04
Built native-first Apple, Google, and Facebook OAuth with JWT exchange, plus SMS OTP onboarding with deferred email verification.
- 05
Established development, staging, and production delivery through GitHub Actions and isolated secrets with AWS Parameter Store.
- 06
Designed direct-to-S3 uploads and authored HLD, data-flow, security, and code-division documentation for leadership and engineering teams.
01 / Challenge
The conditions that shaped the system.
A useful architecture begins with the real constraint.
The simple promise—order before arrival and wait less—crossed many difficult domains: restaurant and menu data, payments, orders, real-time notifications, geospatial discovery, personalised recommendations, mobile authentication, media delivery, and coordinated deployment environments.
02 / System map
From input to outcome
01Diner & restaurant apps
→02NestJS domains
→03Postgres & PostGIS
→04Bedrock & pgvector
→05S3 & CloudFront
→06App Runner delivery
03 / Approach
How the build was organised.
Make the boundaries clear, then move.
- 01
Architected a NestJS and TypeScript modular monolith with clear domains for orders, payments, restaurants, identity, and real-time notifications.
- 02
Built the virtual waitress as a retrieval-augmented system using AWS Bedrock and PostgreSQL pgvector so recommendations stay grounded in available restaurant and menu data.
- 03
Designed an AWS-native production path with App Runner, RDS PostgreSQL/PostGIS, S3, CloudFront, isolated environments, and automated GitHub Actions delivery.
Decisions that carried the product.
Retrieval before response
The dining assistant retrieves menu and restaurant context before composing recommendations based on preferences, restrictions, and budget.
Direct media delivery
Authenticated pre-signed uploads send media directly to S3, protecting API memory and CPU while CloudFront handles low-latency delivery.
What changed after the work.
- ↗Established the scalable backend foundation for diners, restaurants, orders, payments, and live coordination.
- ↗Designed the grounded AI dining assistant and location-aware data architecture.
- ↗Defined repeatable development, staging, and production delivery with security and system documentation for product and engineering teams.
