How We Enabled Horizontal Scaling for a Monolithic App on AWS Cloud

Horizontal scaling is essential for modern applications that expect variable or growing user traffic. Instead of relying on a single powerful machine, it allows the system to distribute load across multiple instances, improving availability and resilience. This approach is more flexible and cost-effective, especially in cloud environments where resources can be added or removed dynamically. For businesses aiming to grow, horizontal scaling ensures the application remains responsive, reliable, and ready to handle demand spikes. 

It was the case on one of our projects, where Axon engineers had to conduct a technical audit to locate weak spots and make the right changes in the system’s cloud infrastructure to enable AWS horizontal scaling for a client with ambitious plans for the future. 

Who Was The Client?

Our client was a proptech platform for business centers, designed to bring together landlords, service providers, tenants, and employees in one digital ecosystem. Here, users can access building details (opening hours, location, transport info) and register visitors, reserve meeting rooms, parking, and other facilities, customize app appearance (logo, colors, modules) to reflect a building’s identity, and even place conference meal orders, view weekly canteen menus, and pay for them with the app.

What Was The Challenge?

At the time when the company contacted the Axon’s team, they were planning a major shift for future growth. Initially, their system combined several mobile apps serving different business centers. This posed a challenge for business scaling as each app would require a dedicated support and development team. To avoid such complexities, the client wanted to make a transition from many to a single scalable app serving many properties. This change, first of all, required a thorough system analysis so that we could understand how to handle the transition in the most efficient way.

What We Revealed

Axon engineers evaluated the entire system infrastructure, architecture, and code, and found out that it required changes at the very core – the infrastructure, as it needed one that would allow horizontal scaling in the AWS cloud. Horizontal scaling allows the application to handle increased user traffic by adding more container instances across multiple servers, rather than upgrading a single machine. This improves availability, fault tolerance, and performance, especially under variable or growing loads.

Initial Infrastructure and Its Pain Points

The app had a cloud-based web application infrastructure deployed in AWS. It had a monolithic architecture, with a single EC2 instance hosting the entire web and application layer. It ran a Laravel back end and an Angular-based front end, both served via an Apache2 web server. Thus, different mobile clients could interact with the backend via HTTP, either consuming Laravel APIs directly or using the Angular-rendered interface. 

But what did we see as major concerns?

Manual Code Pull

The code was manually pulled from GitHub, which meant the absence of a CI/CD pipeline that affected automation, deployment speed, and scalability. Manual deployment from GitHub means high risk for human error, lack of traceability, and slower release cycles. Also, this prevents fast horizontal autoscaling in AWS and recovery — spinning up new instances requires manual intervention or custom scripts.

Monolithic Structure

When the front end, back end, and server are tightly coupled within one EC2 instance, it’s harder to scale or independently update application components. In monolithic architecture, all layers are packed into the same environment (web server, backend, frontend), introducing a lack of separation of concerns or component isolation for independent replication or load balancing.

Single EC2 Instance

In this case, all application components (Laravel, Angular, Apache) had to run on one virtual machine. This enabled vertical scaling well, so that the app could increase its capacity by upgrading the instance size (CPU/RAM), but this option had hard limits and was costly in the long term. The client was looking for EC2 horizontal scaling opportunities.

Summing up, the initial infrastructure was not adapted for horizontal scaling in AWS by design. It was a monolithic, manually managed system tied to a single EC2 instance, which introduced bottlenecks, limited system resilience, and prevented the needed growth.

On the bright side, the system had an implemented DNS abstraction using Route 53: on the networking layer, Amazon Route 53 handled DNS resolution and routed traffic from the mobile client to the EC2 instance. This provided the flexibility (traffic routing based on health checks, latency, or geographic location) so much needed for solution scalability, high availability, and future infrastructure changes. 

It also featured decoupled storage, caching, and database: relying on Amazon RDS (MySQL) for persistent relational data, Amazon S3 for storing static assets such as media files, and ElastiCache for Redis to provide in-memory caching that improved application responsiveness. This way, each component can be scaled or optimized independently, making the system more resilient and easier to maintain or replace individual services.

What Did We Recommend?

Axon’s engineers suggested a new system infrastructure that introduced some significant changes in the client’s infrastructure setup. It was designed to solve the AWS horizontal scaling limitations present in the initial scheme by introducing several elements that address the above-mentioned issues and support horizontal scaling, automation, and resilience.

CI/CD Pipeline

First of all, we recommended introducing a CI/CD pipeline, which is a key step in eliminating manual deployments and reducing errors. With CI/CD automation, GitHub would trigger builds via the AWS CodePipeline service and using the CodeBuild tool. In such a setup, containers can be built, tested, and pushed automatically to a Container Registry and new versions deployed without manual intervention. As a result, the client can have faster and more reliable deployments that ensure horizontal autoscaling within AWS infrastructure without downtime.

Containerized Architecture

Containerization makes the system more modular and scalable. Also, isolation of services improves portability and resource utilization. Thus, we packaged the Laravel back end and Angular front end in Docker containers. These containers can be replicated and deployed on multiple EC2 instances or a container orchestration platform. This would allow the client to spin up more instances of each service on demand. 

Separation of Concerns

We also introduced NGINX and placed it in a dedicated container, decoupled from the back-end and front-end logic, serving the Angular front end as a reverse proxy, handling incoming HTTP requests, and routing them to the appropriate back-end services. At the same time, the front end and back end run in different containers, which allows each to scale independently. Thus, the system can scale the front-end and back-end layers based on their individual load.

Load Balancing
We added an application load balancer to distribute incoming traffic across services that would improve the system’s fault tolerance. Meanwhile, the already present Amazon Route 53 handles DNS-level routing, enabling regional and health-based routing when needed. This way, we could ensure high availability, fault tolerance, and elastic traffic handling for the application.

Logging & Monitoring

Finally, we suggested adding Amazon CloudWatch to handle logging and monitoring. This tool centralizes logs from both containers, builds, and the deployment pipeline, enhancing the system's observability and incident response. Additionally, it supports real-time monitoring, alerting, and diagnostics, resulting in trackable container performance, auto-scale, and easier recovery.

All in all, the new system infrastructure presented a shift from a manually deployed monolith to a containerized, automated, and observable infrastructure, making it significantly more suitable for horizontal scaling in AWS, team collaboration, efficient DevOps, and uptime reliability. The containerized monolith option that we proposed was a major step towards a more modern cloud-native, maintainable, and scalable solution, which is often a necessary stepping stone before true service decomposition.

The Result

As a result of our technical audit for this client, we prepared a solid foundation for further system transformation into a single horizontally scalable application, which:

• Relied on Docker containers for modular deployment.
• Became CI/CD-enabled, ensuring automation and repeatability.
• Could scale horizontally via a load balancer.
• Got easier to monitor, manage, and debug.

How Axon Can Help

As software development professionals, Axon engineers have helped dozens of businesses scale and transform their software projects. And we can tell with certainty that a technical audit is a crucial part for MVPs, early-stage, and legacy solutions looking for a quality upgrade. Without an audit, you can surely scale and grow, but there’s no guarantee that your technical debt, minor infrastructure inefficiencies, or coding weaknesses won’t show up in the worst possible moment, failing your long-awaited V2.0 launch or discouraging a major investor. 

Therefore, we offer a comprehensive system audit to our clients with existing projects to ensure their peace of mind and fix issues when they are insignificant, saving their nerves and budgets. For our technical audit services, we engage our Senior Engineers and Solution Architects with years of hands-on experience in various software projects and deep knowledge of their respective field of expertise. To learn more about this service offering, visit our tech due diligence service page or get in touch with sales representatives at Axon.