🧩 Day 17/30: Monolith vs Microservices — One Big Application or Many Small Services? ☁️
Follow our college portal’s journey as it grows from a single application into a system with multiple services. 🚀 Explore monolithic architecture, microservices, modular monoliths, independent deployment, and the trade-offs of each approach to learn how to choose the right architecture for your application.
Series: Cloud Computing (25 articles)
- …
- 18🧩 Day 17/30: Monolith vs Microservices — One Big Application or Many Small Services? ☁️ This article
🧩 Day 17/30: Monolith vs Microservices — One Big Application or Many Small Services? ☁️
🎮 Mission 17: The College Portal Is Getting Too Big!
Remember Rahul and our college examination portal?
We started with a simple idea: build a website where students can register for examinations.
But look how far we've come! 🚀
Our portal now supports:
- 👨🎓 Student registration
- 🔐 Secure login and access control
- 🗄️ Student records and examination results
- 🪣 Document and profile-picture storage
- ⚖️ Load balancing
- 📈 Auto Scaling
- 🌍 Content delivery through Amazon CloudFront
- ⚡ Serverless functions using AWS Lambda
- 📨 Background processing with Amazon SQS
Everything is working.
But the college has a new announcement!
"We're launching online payments, examination scheduling, automated notifications, and a new results dashboard!"
The development team celebrates. 🎉
Then the lead developer opens the codebase.
One application contains the registration logic, payment logic, notification logic, examination scheduling, and reporting functionality.
Every new feature seems to affect something else.
A small change to the payment feature breaks the registration page.
A reporting update requires the team to test the entire application.
Deployments are becoming more complicated.
Rahul asks:
"Can we organize our application so that every feature doesn't depend on everything else?"
The cloud architect smiles.
"That's the question that leads us to Monoliths and Microservices!"
🏢 1. Meet the Monolithic Application
Let's start with a simple architecture.
A monolithic application is an application built and deployed as one unit, even though it may contain many internal modules.
Imagine our college portal contains five major features:
- Student registration
- Examination management
- Payments
- Notifications
- Reporting
In a monolithic architecture, these features can live inside one application.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
👨🎓 Students
|
v
Load Balancer
|
v
+----------------------+
| College Portal App |
| |
| Student Registration|
| Examination System |
| Payments |
| Notifications |
| Reporting |
+----------------------+
|
v
DatabaseNotice something important.
One application contains multiple features.
That doesn't mean the code must be messy. A monolith can have well-organized modules, clear boundaries, and excellent internal design.
The defining characteristic is that the application is deployed as one unit.
🏫 Real-world analogy
Imagine one large college office.
Inside the office, there are separate desks for registration, payments, examinations, and notifications.
Each desk has its own responsibility, but they all operate inside the same office.
That's our monolith!
🧠 2. Is a Monolith Bad?
Absolutely not!
This is one of the biggest misconceptions in software architecture.
A monolith can be an excellent choice, especially when:
- The application is small or medium-sized.
- The development team is small.
- The features are closely related.
- The team wants straightforward development and deployment.
- The application doesn't yet need independent scaling for different features.
Imagine a college portal that only supports student registration and viewing examination schedules.
Would we immediately need ten separate services, multiple deployment pipelines, distributed monitoring, and a complex network of service-to-service communication?
Probably not.
A well-structured monolith could be simpler, cheaper, and easier to maintain.
The goal isn't to avoid monoliths. The goal is to choose an architecture that fits the application's needs.
🚨 3. When Our Monolith Starts Growing
Now imagine the college portal becomes extremely popular.
Millions of students use it across multiple campuses.
The college adds new features every month.
The development team grows from three developers to fifty.
Different teams work on payments, registrations, reporting, and notifications.
New challenges appear.
Problem 1: Deployments become difficult
A small change in one feature may require building, testing, and deploying the entire application.
Problem 2: Teams become dependent on one another
Developers working on payments may need to coordinate with the registration team before releasing a change.
Problem 3: Different features need different resources
The reporting module may need significant processing power, while notifications need much less.
Problem 4: One defect can affect more functionality than expected
A problem in a shared component may affect several features inside the application.
These problems don't automatically happen in every monolith, but they can become harder to manage as an application grows.
Rahul asks:
"Can we separate these features so that each team can work more independently?"
The architect replies:
"Yes. One option is a microservices architecture."
🧩 4. What Are Microservices?
Microservices architecture organizes an application as a collection of smaller services, each responsible for a specific business capability.
Instead of putting every feature inside one deployable application, we can separate major capabilities into services with clearly defined responsibilities.
For our college portal, we might have:
- Student Service
- Registration Service
- Payment Service
- Notification Service
- Reporting Service
Conceptually:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
👨🎓 Students
|
v
API / Gateway
|
+-------------+-------------+
| | |
v v v
Registration Payment Student
Service Service Service
| | |
+-------------+-------------+
|
v
Other Services
Notifications / ReportingEach service can have its own codebase, deployment process, and scaling configuration, depending on how the system is designed.
The services communicate through APIs, messages, or other defined interfaces.
🏫 Real-world analogy
Imagine our college has separate departments:
- The registration department handles registration.
- The accounts department handles payments.
- The examination department manages exam schedules.
- The communication department sends notifications.
Each department has its own responsibility.
They coordinate when necessary, but they don't all have to operate as one giant department.
That's the basic idea behind microservices.
⚖️ 5. Monolith vs Microservices: The Big Comparison
Let's compare both approaches.
| Feature | Monolithic Architecture | Microservices Architecture |
|---|---|---|
| Application structure | One deployable application | Multiple independently deployable services |
| Deployment | Usually deploy the application as one unit | Services can be deployed independently |
| Scaling | Often scales the application as a whole | Individual services can scale separately |
| Development | Can be simpler initially | Requires service boundaries and coordination |
| Communication | Often uses internal function calls | Often uses APIs or messaging between services |
| Testing | Easier to test some workflows in one process | Integration and distributed-system testing become important |
| Failure handling | A failure may affect multiple functions in the application | Services can be isolated, but failures can propagate through dependencies |
| Operations | Often simpler to operate initially | Usually requires more monitoring and operational discipline |
| Best fit | Many small and growing applications | Systems that benefit from independent ownership, deployment, or scaling |
Remember: these are general patterns, not absolute rules.
A poorly designed monolith can be difficult to maintain, and a poorly designed microservices system can be even more difficult.
🏗️ 6. Let's Redesign Our College Portal
The college decides that payments and notifications now need to evolve independently from registration.
Our architect proposes separating those capabilities.
Before: Monolithic Architecture
1
2
3
4
5
6
7
8
9
10
11
College Portal
|
+--------------+--------------+
| | |
v v v
Registration Payments Notifications
| | |
+--------------+--------------+
|
v
DatabaseAll three features belong to one deployable application.
After: Microservices Architecture
1
2
3
4
5
6
7
8
9
10
11
12
13
14
👨🎓 Students
|
v
API Gateway
|
+-----------+-----------+
| | |
v v v
Registration Payment Notification
Service Service Service
| | |
v v v
Data Store Payment Messaging
System ServiceThis is a simplified conceptual diagram. In a real design, each service's data ownership and integrations would be defined carefully.
The important change is that registration, payments, and notifications now have distinct service boundaries.
For example, the team could update the notification service without necessarily redeploying the registration service.
That's one of the major benefits of microservices.
🔌 7. How Do Microservices Talk to Each Other?
This is where our Day 16 lesson becomes useful!
Remember Amazon SQS?
We learned that message queues allow components to exchange work without requiring the consumer to process it immediately.
Now let's connect that concept to microservices.
Imagine Rahul successfully registers for an examination.
The Registration Service saves the registration.
It then publishes a message indicating that registration has been completed.
1
2
3
4
5
6
7
8
9
10
11
12
Registration Service
|
v
Amazon SQS
|
+---------+---------+
| |
v v
Notification Worker Reporting Worker
| |
v v
Send Confirmation Update ReportNow the registration service doesn't have to wait for every background operation to finish.
The notification and reporting workflows can process the message independently.
This is called asynchronous communication.
Microservices can also communicate synchronously through APIs when an immediate response is needed.
Important lesson
Not every service needs to call every other service directly.
Good architecture minimizes unnecessary dependencies and makes service responsibilities clear.
🗄️ 8. Should Every Microservice Have Its Own Database?
Here's a common architecture question.
Suppose we have:
- Registration Service
- Payment Service
- Notification Service
Should all three directly read and write the same database tables?
If every service depends on the internal tables of every other service, the system can become tightly coupled again.
A common microservices principle is:
Each service should own its data and expose the information other services need through defined interfaces or events.
Conceptually:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Registration Service
|
v
Registration Data
Payment Service
|
v
Payment Data
Notification Service
|
v
Notification DataThis doesn't necessarily mean every service must use a separate physical database server.
Data ownership can be logical, and the exact storage design depends on the system.
The goal is to prevent services from becoming dependent on each other's internal data structures.
⚠️ 9. Microservices Introduce New Challenges
Microservices sound exciting.
Independent deployments!
Independent scaling!
Separate teams!
But there's a catch.
Microservices move some complexity from inside one application into communication and coordination between multiple services.
Let's explore some challenges.
1. Network failures
One service might be healthy while another is unavailable.
2. Increased operational complexity
We need to monitor multiple services, deployments, logs, metrics, and dependencies.
3. Data consistency
A business operation may involve multiple services, making transactions more complicated.
4. Debugging
A single user request might travel through five different services.
Finding the cause of a failure can require distributed tracing and correlated logs.
5. Security
Each service and communication path needs appropriate authentication, authorization, and network controls.
6. Cost
More services may mean additional infrastructure, observability, networking, and engineering overhead.
Microservices aren't a shortcut to good architecture.
They require good architecture.
🎯 10. The Smart Alternative: A Modular Monolith
Now here's something many beginners miss.
Our choice isn't always limited to:
- One giant, tangled application.
- Dozens of independent microservices.
There's another option: a modular monolith.
A modular monolith is one deployable application organized into well-defined internal modules.
For example:
1
2
3
4
5
6
7
8
9
10
11
College Portal Application
|
+--------------+--------------+
| | |
v v v
Registration Payments Notifications
Module Module Module
| | |
+--------------+--------------+
|
Defined InterfacesThe modules share one application deployment, but their responsibilities and interfaces are kept clear.
Why is this useful?
Because if the college portal is still relatively small, the team can maintain a straightforward deployment while keeping the code organized.
Later, if the payment module genuinely needs independent scaling or deployment, the team can consider extracting it into a separate service.
A modular monolith can be a practical starting point for a system that may grow into microservices later.
🧠 11. When Should We Choose Each Architecture?
Let's imagine three scenarios.
Scenario A: A Small College Portal
The application has student registration, exam schedules, and basic result viewing.
The development team has four people.
The system is relatively straightforward.
A modular monolith is a strong starting point.
Why?
- Simpler deployment.
- Easier local development.
- Fewer distributed-system problems.
- Clear internal organization.
Scenario B: A Growing University Platform
The platform has multiple development teams, and payments and registrations have different release schedules.
Microservices may be worth considering for selected capabilities.
Why?
- Teams can own services independently.
- Services can be deployed separately.
- Different components can scale according to their needs.
Scenario C: A Global Examination Platform
The platform serves many institutions and includes separate payment providers, scheduling systems, identity services, and reporting pipelines.
A distributed architecture may be appropriate, but it needs careful design for reliability, security, observability, data ownership, and failure recovery.
The right architecture depends on business needs, not popularity.
🔥 12. The College Portal Faces a Real Problem
It's Monday morning.
The examination registration deadline is approaching.
The Registration Service is handling a large number of requests.
Meanwhile, the reporting service is processing yesterday's registrations.
The notification service is sending confirmation messages.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
👨🎓 Students
|
v
Registration
Service
|
v
Registration DB
|
v
Amazon SQS
|
+--------+--------+
| |
v v
Notification Reporting
Service Service
| |
v v
Emails ReportsSuddenly, reporting becomes slow.
What should happen to new registrations?
Ideally, the registration workflow should continue as long as its own critical dependencies are healthy, while reporting catches up later.
A queue can help isolate background processing from the immediate registration workflow.
But this isn't automatic magic. If the architecture contains synchronous dependencies on the reporting service, registration could still be affected.
The design must deliberately separate the critical path from background work.
Rahul checks the portal.
1
2
3
Registration Status: Successful
Confirmation Email: Processing
Daily Report: PendingThe student has completed the important operation, while background tasks continue independently.
That's the kind of behavior we want from a well-designed system.
🧩 13. Connecting Day 1 to Day 17
Let's review our journey.
- Day 1: What is cloud computing?
- Day 2: Traditional IT vs cloud computing.
- Day 3: What does cloud architecture look like?
- Day 4: IaaS, PaaS, and SaaS.
- Day 5: Regions and Availability Zones.
- Day 6: High availability and fault tolerance.
- Day 7: Virtual machines and EC2.
- Day 8: Cloud storage.
- Day 9: Cloud databases.
- Day 10: Cloud networking.
- Day 11: Security and IAM.
- Day 12: Load balancing.
- Day 13: Auto Scaling.
- Day 14: CDN and CloudFront.
- Day 15: Serverless computing.
- Day 16: Message queues and asynchronous processing.
- Day 17: Monoliths and microservices.
Notice how the topics connect.
We learned how to run an application, secure it, scale it, deliver its content faster, process background tasks, and now organize its growing functionality.
We're moving from individual cloud services toward complete system design.
🎮 14. Mini Challenge: Choose Your Architecture
You're now the cloud architect for our college portal.
Challenge 1
The application is small, and a team of three developers maintains it.
Which would be a sensible starting point?
A. Create 25 microservices immediately.
B. Build a well-structured monolith with clear internal modules.
C. Give every function a separate database server.
Answer: B.
A modular monolith may be simpler to build, test, deploy, and maintain at this stage.
Challenge 2
The payment team needs to deploy its service independently from the registration team.
Which architecture can support this more naturally?
A. A microservices architecture with clear service boundaries.
B. One application that must always be deployed as a single unit.
C. A shared source-code folder without defined interfaces.
Answer: A.
Independent deployment is one of the benefits microservices can provide.
Challenge 3
Our notification service can process tasks asynchronously.
Which Day 16 concept can help buffer notification work?
A. Amazon SQS.
B. An Availability Zone.
C. An IAM policy by itself.
Answer: A.
SQS can queue messages until consumers are ready to process them.
Challenge 4
The team wants microservices because everyone says they're modern, but the application is still small and easy to maintain.
What should the architect do?
A. Split everything immediately.
B. Evaluate actual requirements, complexity, team structure, and scaling needs.
C. Assume microservices are always cheaper.
Answer: B.
Good architecture begins with requirements, not trends.
🏆 Mission Complete!
Today, we discovered two different ways to organize an application.
🏢 Monolithic Architecture
Multiple application features live inside one deployable unit.
🧩 Microservices Architecture
The application is divided into smaller services that can be developed and deployed independently.
🧠 Modular Monolith
One deployable application contains clearly separated internal modules.
The most important lesson?
A monolith is not automatically bad, and microservices are not automatically better.
Choose the simplest architecture that satisfies the application's requirements, and introduce complexity when it delivers a meaningful benefit.
Our college portal is growing, but we don't have to split every feature into a separate service just because we can.
We need clear boundaries, reliable communication, good security, and an architecture that the team can operate successfully.
🚀 Coming Up on Day 18/30
🐳 Containers & Docker — How Do We Package an Application So It Runs Consistently Everywhere?
Our college portal now has a growing set of modules and services.
But Rahul's development team has a new problem.
The application works on one developer's laptop.
It fails on another developer's machine.
Then it behaves differently in testing.
The team keeps hearing:
"But it works on my machine!" 😭
What if we could package the application together with its runtime dependencies into a consistent unit?
That's where containers and Docker come in.
On Day 18, we'll explore:
- 🐳 What is a container?
- 📦 What is Docker?
- 🆚 Containers vs virtual machines.
- 🧱 What is a container image?
- 🚀 How do containers help applications run consistently?
- ☁️ How can containers fit into our AWS architecture?
Our journey is moving from designing cloud systems to packaging the software that runs inside them.
☁️ Build it. Secure it. Scale it. Accelerate it. Automate it. Connect it. Architect it.
#CloudComputing #AWS #CloudArchitecture #Monolith #Microservices #SoftwareArchitecture #AmazonSQS #30DaysOfCloud
Series: Cloud Computing (25 articles)
- …
- 18🧩 Day 17/30: Monolith vs Microservices — One Big Application or Many Small Services? ☁️ This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article