A cloud-native platform that deploys itself, scales on demand, and never loses sight of a request

The problem: the hard part isn't the code

Any full-stack developer can write an order service. The part that separates a demo from a system real users depend on is everything around the code: how it deploys, how it survives a traffic spike, how you find out the moment it breaks, and how you keep secrets out of it. That operational half is usually invisible in a portfolio — so this project is built to make it the entire point.

Four small services — a product catalog, a cart, an order service, and a background notification worker — become the stage for the real work: infrastructure as code, a passwordless delivery pipeline, private networking, autoscaling, async messaging, distributed tracing, and identity-based security. The services are kept deliberately simple so the platform underneath can be the star.

Everything is code — one git push ships the whole cloud

There's no clicking around the Azure portal. The whole system is declared as code and rolled out by a pipeline that runs on every push to main:

• Terraform defines every resource — the container environment, all four services, Redis, the Service Bus queue, Application Insights, the alert rules, and the identities — with remote, locked state, so a pull request shows an exact plan of what will change before anything does.
• GitHub Actions logs into Azure with OIDC — a short-lived federated token, never a stored secret — then builds a Docker image per service, tags it with the immutable git commit SHA, and runs terraform apply.
• A generic build step means a brand-new service is just a new folder with a Dockerfile: the pipeline discovers it and rolls it out as a zero-downtime revision automatically.

Built to take a traffic storm

The services are stateless by design, so Container Apps can run one copy or fifty behind a load balancer without changing a line. KEDA drives the autoscaling: the public services scale out under HTTP load, while the notification worker scales on how many messages are waiting — all the way down to zero replicas when the queue is empty, so idle work costs nothing.

Three patterns keep it calm under pressure. The product catalog lives on a private network, unreachable from the internet and callable only by its sibling services. A Redis cache-aside layer absorbs repeat catalog reads, so a burst never stampedes the source. And ordering follows save-then-publish: an order is accepted, an event is dropped onto a Service Bus queue, and the worker drains that queue on its own schedule — turning a spike of orders into a calm backlog instead of a cascade of failures.

You can't run what you can't see

Every service is instrumented with OpenTelemetry and reports to Azure Application Insights, so a single request can be followed as it hops from the order service to the catalog and out to the queue — one continuous distributed trace across process boundaries. An Application Map draws the live topology automatically, with latency and error rates on every edge.

On top of that sits alerting: a rule watches the failed-request rate, and when it crosses a threshold an action group sends an email within minutes — then auto-resolves once the system recovers. The whole loop was verified end to end by deliberately breaking a service and watching the alert fire and then clear on its own.

Secure by default — and built to scale

No password lives anywhere in this system. Images are pulled with a managed identity instead of registry credentials — the registry's admin login is switched off entirely — CI authenticates with OIDC, and the message queue is reached with least-privilege keys: the order service may only send, the worker may only listen. Each component holds exactly the rights it needs and nothing more.

The architecture is honest about its ceiling. As built, the stateless compute and autoscaling comfortably carry a single region toward roughly a million users; beyond that, the same design goes multi-region behind Azure Front Door, with the data tier promoted to read replicas or a sharded store. The point isn't a finished product — it's a platform that knows exactly where its next bottleneck is and how to move it.