Blog

Monoliths Explained: The Architecture I Kept Hearing About at My First Internship



The First Standup


It was my first standup meeting at my internship, and honestly, I had no idea what was going on.


There were so many words being thrown around that I didn't understand, and I just kept nodding along, hoping no one noticed. But out of everything mentioned, there was one word that kept coming up — monolith.


Monolith this. Monolith that. The monolith needs an update.


The more they said it, the more it seemed like this word was the most important thing in the world, and everyone else knew exactly what it meant.


Meanwhile, I was sitting there, smiling and nodding, secretly Googling "What is a monolith?". To my surprise, the search didn't help me much, and I left the meeting just as confused as I entered it.


When the weekend came around, I decided enough was enough. I wasn't going to spend another week feeling clueless. I was going to figure out what this "monolith" thing actually was.


So… What is a Monolith?


In simple terms, a monolith is a single, unified application. All the parts of the app — backend, frontend, and database logic — live together and are deployed as one unit.


Imagine a large office building where different departments are all located in the same structure. Each department has its own space, but everything is still connected. If you want to change the layout of one department, it might be a small update. But if you make bigger changes, you have to think about how those changes affect the rest of the building.


In a monolithic application, updates or deployments happen to the whole system together, even if you only changed one part. This can make it easier to manage when starting out, but it can become more challenging as the system grows in size and complexity.


One of the other big names you'll hear in the same conversation is microservices. Microservices take the opposite approach: instead of one large application, you break it into smaller, independent services that can be deployed and updated separately.


Quick Peek: Monolith vs Microservices


If a monolith is one large office building, microservices are like separate office buildings for each department. Each building can be renovated, moved, or expanded without touching the others.


This can make scaling and maintaining easier, but it also comes with challenges like making sure all the buildings can communicate effectively and work toward the same goals.


Other Common Architectures You'll Hear About


While monoliths and microservices are two of the most talked-about patterns, there are a few others you'll hear in meetings and tech discussions:


  • Layered (n-tier) — Separates code into layers like presentation, business logic, and data access.

  • Event-Driven — Services communicate by producing and consuming events, often in real time.

  • Serverless — Runs application code in cloud-managed functions without provisioning servers.

  • Understanding these will help you see the bigger picture when people talk about "system design" or "architecture" in a professional setting.


    Wrapping Up


    So that's the mystery behind the "monolith" I kept hearing about in my first standup. It is not a secret project name. It is a way of building software that is still common today, especially for projects in their early stages.