Cinema Seat Reservation System — Part 2: Transitioning To Production-Scale and Deploying on Azure Cloud

Mazen Aly — Wed, 24 Jun 2026 06:26:12 +0000

Introduction

This is the second part of sharing my journey to create a microservices-based backend system, in the previous part, I introduced the system and its services.
In this part I am going to mention the main things that happened with me from then until now.

Transitioning to online DBaaS platforms

The first main thing was to transition my databases from my local device to accessible over the internet. I used Neon and MongoDB Atlas. Although performance-wise it is better to deploy the database on the same server that the whole system so all services can access the databases without network overhead, This solution is better from a point, that is avoiding consuming the free VM instance that I got to host my main services, as with DBaaS platforms I will not require storage for databases or additional overhead to handle the DBMS on a free small resources-constrained VM.

Observability

Observability is one of the main concerns in any system, it gives the ability for the system to expose what happens inside it without any need to guess and manually trace the code to determine where the error may happened.
I utilized OpenTelemetry, as I found it is most used and accepted tool to log, trace and collect metrics about the system and the traffic. Also, I loved that it is not related to specific framework, that is .NET by the way, I loved the idea that it is standalone tool.
But logging and tracing and metrics collection will not be beneficial if we do not see it actually and can achieve monitoring from those telemetry data, so I used Grafana Cloud to export the telemetry data to some place that is accessible online and a tool that can generate dashboards and visualizing for the metrics (Prometheus), and UI that can show all the telemetry data easily.

Resilience

I achieved resilience in this system, by implementing Retry and Circuit-Breaker Pattern, that applies retires and mitigates the effect transient failures, so user can not know that there is actually a failure happened.
Without it, any HTTP transient failure when calling a downstream service will lead to Internal Server Error response directly, even there is no permanent failure in the downstream service.

Deployment

Until this point, we have a system that is fully functional and have consistent docker configuration for its services via Docker Compose, and it database is already there and available.

Now this is the point at which I wanted my system to be online and accessible from everywhere over the world, and really reach the goal: From Baseline Local Development To Live Cloud-Native Production.

For this I chose Azure Cloud Services, I had a virtual machine on Azure Cloud and installed Docker on it, also I configured the firewall so it added two ports to access my system, one for Identity Service, and the another one is for API Gateway.

What I did is as follows:

I created images from my actual code on my local machine, and pushed it to GitHub Container Registry.
I issued a token from GitHub to allow Docker engine that is installed on the virtual machine to actually pull and push the images (it is called Packages of type containers on GitHub) from and to my GitHub account.
I copied (via SCP) Docker Compose file with secret env variables file, from my local machine to the online Azure VM. Now the VM has Docker engine, and the ability to access any uploaded images on GitHub and pull/download them on the VM.
Finally, I executed the command: docker compose pull to pull images from GitHub Container Registry then docker compose up and to spin up the containers from them.
Voilà! the system became live and accessible online.

And now, we have a live production-scale cloud-native application.

See GitHub Release, Capturing Project at This Point

Workflow

After I had this whole setup, my workflow became very consistent, it is as follows:

Make a change in the code, fixing a bug or enhance codebase or add a feature, then push it to GitHub, every change should be pushed to GitHub to achieve CI (continuous integration) practice in software development, that is simply the practice of merging the new code changes to the branch and then get automatically tested and checked, and this is achieved by the CI Pipeline that I built using GitHub Actions.
Then I directly rebuild the images so I get the latest changes on the code reflected on the new images.
I push these latest versions of images to GitHub Online Registry.
I access the VM through SSH, delete the old docker-compose.yml and .env files if they are modified.
Rerun the docker compose commands to pull the latest images from GitHub Container Registry and spin up new containers and delete the old containers. So, CD (Continuous Deployment/Delivery) is achieved here (manual CD workflow).

Conclusion

In conclusion, I want to say that this project made me learn many valuable skills, concepts and tools. There are many another things that not mentioned to keep things brief (you can get some of them by taking a look on GitHub Repository that is mentioned in Part 1 from this series, and view the commits history), and focus on the points that I feel that it really matters and think that readers can learn from it.

Take a look on this series title, we really transitioned from "Baseline Local Development" that is the MVP that runs on my machine, to "Live Cloud-Native Production" that actually appeared in observability setup and deploying on Cloud and making it accessible online.

If you have questions or feedback, drop them in the comments. I hope I can learn from or add benefit to one of you

Next Steps

For now, I am testing the system to determine its bottlenecks, for sure it has many areas of improvement, and things that even can be added to this project to make it better and more performant, I am going to mention some bugs and issues that faced me and how I overcame it and learned from them and some decisions that I made in the system. This what I will mention in the next part "Bugs, Decisions and Areas Of Improvement".

Cinema Seat Reservation System — Part 1: Overview & Architecture

Mazen Aly — Tue, 26 May 2026 08:11:09 +0000

Introduction

I am writing this series of blog posts to document what I am learning while building a project. You are welcome to criticize and guide me toward areas of improvement — or maybe, and I genuinely hope this, I can introduce you to concepts or ideas you haven’t encountered before, so we both can grow. I will focus on architectural and design concepts and the technologies that can be applied regardless of your framework and programming language of developing the application.

GitHub Repository

There you can find more details, including ADRs (Architectural Design Records) and more extensive documentation.

mazenaly256 / Cinema-Seat-Reservation-System

Cloud-native microservices-based cinema seat reservation system developed in ASP.NET with REST API, featuring deliberate system design decisions. Designed for modularity and scalability.

Cinema Seat Reservation System

A cloud-native, microservices-based ecosystem developed in ASP.NET Core with REST APIs. This system features deliberate design decisions optimized for modularity, scalability and resilience — implementing proven distributed systems patterns such as Retries and Circuit Breakers and Request Timeouts alongside automated CI/CD pipelines.

Architectural Overview

Diagram

Services

Movie Service: Responsible for movies and showtimes.
Reservation Service: Responsible for seats layout representation and seat reservation.
Identity Service: Acts as the centralized Identity Provider (IdP) for the system.
API Gateway: Centralizes the logic of authentication and applies rate limiting, timeouts, and routing policies for all incoming traffic.

API Documentation

Postman API Workspace

View on GitHub

System Overview

I have built a microservices-based backend system, for handling seat reservations in a cinema, each service has its own database. I applied many new concepts that I have learned including how to split the system and build the architecture that offers the modularity and future scalability for the application, building and securing API endpoints using JWT, implementing an API gateway to be the single entry point for my whole system, building a basic CI Pipeline using GitHub Actions, containerizing the services with configuring and running together via Docker Compose.

Services

Movie Service: Responsible for CRUD operations on movies and showtimes, and enforces role-based access control.

Reservation Service: Responsible for handling seats availability checks and the logic of seats reservations and payment.

Identity Service: Acts as the centralized Identity Provider for the whole system, responsible for storing and managing users and issuing JWT tokens that are trusted across all the system.

API Gateway: The single entry point for the system, acting as an architectural AOP (Aspect-Oriented Programming) layer. It centralizes cross-cutting concerns like authentication, rate limiting, and request timeouts in one place instead of duplicating their logic across all the system services. In addition to the main responsibility of API Gateway that is forwarding the requests to downstream services.

System Architecture

GitHub Release

Next Steps

What I am going to do in my next few posts, is to document the main points of transitioning this system from the development phase on my local machine to a fully deployed, cloud-native, production-scale system.

DEV Community: Mazen Aly

Cinema Seat Reservation System — Part 2: Transitioning To Production-Scale and Deploying on Azure Cloud

Introduction

Transitioning to online DBaaS platforms

Observability

Resilience

Deployment

See GitHub Release, Capturing Project at This Point

Workflow

Conclusion

Next Steps

Cinema Seat Reservation System — Part 1: Overview & Architecture

Introduction

GitHub Repository

mazenaly256 / Cinema-Seat-Reservation-System

Cloud-native microservices-based cinema seat reservation system developed in ASP.NET with REST API, featuring deliberate system design decisions. Designed for modularity and scalability.

Cinema Seat Reservation System

Architectural Overview

Diagram

Services

API Documentation

System Overview

Services

System Architecture

GitHub Release

Next Steps