Enterprise Web Platform on Azure

The setting

Internal platforms for Starbucks’ Store Development organization — the tools behind real estate, leases, and store imagery for thousands of locations. Enterprise constraints applied to everything: security review before deployment, cloud and firewall teams to coordinate with, an architecture board with real veto power, and users who file tickets when something is down for ten minutes.

The architecture

The core application was a React frontend and a Node/Express backend on MongoDB — ordinary enough on a whiteboard. What made it interesting was the infrastructure discipline underneath.

The React frontend ran on two Linux VMs behind an Azure load balancer, with Azure Front Door at the edge handling routing, caching, SSL termination, and WAF. The backend lived on its own VMs in a separate subnet, and here’s the part I still bring up in interviews: the backend API had no public IP path at all. NSG rules allowed traffic only from the frontend subnet, over private IPs, inside the VNET. If you weren’t the frontend, you couldn’t reach it. PM2 kept the Node processes alive across the fleet; Datadog and Splunk told us how everything was breathing; Azure DevOps ran build, test, and release.

Users

↓→

Azure Front DoorCDN · SSL · WAF

↓→

Load Balancer

↓→

Frontend VMs ×2React · PM2

private IP only — NSG enforced↓→

Backend VMsNode / Express

↓→

MongoDB

• Public internet → Backend VMs: no route

Three pieces of work I’d defend on a whiteboard

The SSO integration. Passport.js with SAML, federated against the enterprise Microsoft identity provider. SSO looks simple in a diagram and never is: SAML request handling, relay state, home realm discovery, session behavior across the BFF. We ran an Express Backend-for-Frontend specifically so tokens never touched the browser beyond what the pattern requires. I later became the tier-3 escalation point for SSO issues across teams, which is the strongest proof I actually understood it.

The database migration. The backend originally ran on Cosmos DB with a Redis cache in front. Both worked; together they were more system than the workload needed — two services to operate, tune, and pay for. I migrated it to MongoDB, collapsed the cache layer, and the result was a simpler stack with real cost savings. The lesson I took: the best infrastructure change is often subtraction.

The NiFi pipelines. I built custom Apache NiFi processors for data ingestion and transformation feeding ERP integrations. Custom processors have a high bar at Starbucks — the enterprise architecture team has to approve them for production. Mine were approved and deployed.

Security as part of the job

I produced the cloud-security review artifacts myself: architecture diagrams showing components, data flows, open ports, and security configs — then did SQL-injection hardening on both frontend and backend as findings came back. Doing your own security review changes how you write code afterward. It’s why segmentation and least-exposure show up unprompted in everything I’ve built since.

The outcome

Promoted from Application Developer I to II. Trusted with tier-3 production escalations. And in 2024, a Next.js + MongoDB application I built to host the annual Hackweek event earned a Bravo Award and was adopted company-wide.