Introduction
I have been building CRUD applications for a long time, during my previous job, internships, and university assignments.
In a typical CRUD application, your project is divided into three major components.
Front-end: Built using HTML, CSS, JavaScript, and frameworks or libraries like React, Angular, or Vue.
Back-end: APIs built using Java with Spring Boot, Python with Django or Flask, or Node.js and Express.
Database: Where all data is stored and retrieved, using SQL databases such as MySQL or PostgreSQL, or NoSQL options like MongoDB.
This structure is often called a 3-Tier Architecture because the application is basically divided into three layers: frontend, backend, and database.
My Assumption About Microservices
Eventually, I learned about Microservices architecture, or at least I thought I did. To me, a microservice was simply a service running independently and communicating with others using REST APIs. This assumption led me to believe that if I ran my frontend, backend, and database inside Docker containers and made them communicate via REST, I was actually building a microservices-based application.
I even built such an application using Java Spring Boot, React, and MySQL, which you can check out at : Building a Full-stack ERP
Monolithic Architecture
While studying Microservices architecture again, I realized I was completely wrong. What I had built was still based on a Monolithic Architecture and not microservices.
In a Monolithic Architecture, the frontend, backend, and database all live in a single codebase and are tightly coupled. This makes it easy to get started, but as the application grows, it becomes difficult to scale, maintain, and deploy safely.
In this type of application, different teams, such as the Accounts Dev Team, Loans Dev Team, Cards Dev Team, and the UI/UX Dev Team, push their updates to the same codebase. The code is then built using tools like Jenkins and deployed to a single server, which means that even small changes affect the entire application.
You can think of a monolithic application like a Jenga tower. All the blocks are stacked together, and each one depends on the others for stability. If you remove or change just one block, for example, a part of the backend or database, the entire application could break, just like the tower collapsing. This shows why monolithic apps are fragile and harder to scale as they grow
Why I Thought My 3-Tier App Was a Microservice
For the longest time, I believed my 3-tier CRUD apps were microservices. On the surface, it looked like I had independent services. There was a frontend running in React, a backend API layer in Spring Boot, and a MySQL database. Each layer ran in its own Docker container, communicating with the others through REST APIs. To me, this seemed like the perfect example of microservices in action.
Looking back, I feel like a dumbass. I had confused containers and APIs with true microservices. Just because something runs separately in Docker does not mean it is independently deployable or truly independent.
What Are Microservices?
A microservices architecture is a way of building applications as a collection of small, independent services, each responsible for a single feature or business capability. Each service:
Has its own codebase and can be deployed independently.
Can have its own database or data storage.
Communicates with other services through APIs or messaging systems.
Can be built using different technologies depending on what fits best.
In a microservices architecture, different teams such as the Accounts Dev Team, Loans Dev Team, Cards Dev Team, and the UI/UX Dev Team each own their own independent service and codebase. Each team can build, test, and deploy their service without waiting for others. These services are usually deployed in containers or cloud environments, often with their own databases, and communicate with other services using APIs or messaging systems. This means that small changes in one service do not require redeploying the entire application, and updates can be rolled out more frequently and independently.
Think of it like a team of specialized chefs in a restaurant. Each chef focuses on a single dish and can cook independently. If the pastry chef is busy, the rest of the kitchen can still function. In contrast, a monolithic app is like one chef trying to cook all dishes at the same time; if they get sick, the whole restaurant suffers.
Microservices make applications more scalable, resilient, and easier to maintain at large scale, but they also introduce extra complexity, like communication between services and monitoring.
Why My 3-Tier App Was Still Monolithic
Even though I had three separate layers, my application was still monolithic because:
All the backend logic lived in a single codebase.
The frontend, backend, and database were tightly coupled.
If one part failed, it could affect the whole system.
Any schema changes in the database or major updates in the backend could break other parts of the application.
Scaling was limited. I could scale the backend as a whole, but I could not scale individual features or services independently.
In contrast, microservices allow you to scale each service based on its own needs.
The Real Difference
Here is a small table that will help you differentiate between Monolithic and Microservices Architecture:
A true microservice is independently deployable, owns its own data, and communicates with other services via APIs. One service can fail, be updated, or scaled without affecting the others. My 3-tier apps, no matter how nicely divided into frontend, backend, and database layers, were still a single, unified application. They were layered, not independent.
A Simple Thumb Rule
If it scales and deploys as one unit, it’s monolithic. If it scales and deploys in parts, it’s microservices.
Takeaways
The words layers and services can be confusing. The important lesson is understanding the difference now and knowing that separation alone does not make an application a microservice. Running things in Docker and communicating via APIs is useful, but it does not automatically make your app a microservice.
The real takeaway is that learning architecture is a journey. Mistakes like this are part of the process, and understanding them makes you a better developer. At the same time, it is worth remembering that microservices are not perfect either. They introduce added complexity with service-to-service communication, monitoring, testing, and deployment pipelines. Choosing between monolithic and microservices should always depend on the scale and needs of the application.
Top comments (0)