What it is: Everything lives in one codebase and deploys as a single unit. UI, business logic, and data access are all tightly coupled — one big deployable artifact (a JAR, WAR, or executable).
How it works: A request hits the UI layer, passes through the business logic layer, hits the data access layer, and writes to one shared database. All in the same process, same memory space.
Real-world example: Early PayPay, early Rakuten. Most large companies started monolithic. Your first Spring Boot app with controllers, services, and repositories in one project is a mini monolith.
Advantages: Simple to develop initially, easy to debug (one process, one log), no network overhead between layers, easy to test end-to-end.
Disadvantages: As the codebase grows, it becomes impossible to understand. One bug can bring down the entire system. You cannot scale just one feature. You scale the entire app. Deployments become risky and slow. Teams start stepping on each other’s code.
When it breaks down: When you have more than 10 engineers, when different features have wildly different scaling needs, or when deployment speed matters.
Interview and blog angle: Every architecture starts monolithic. The question is knowing when to break it apart.
What it is: The application is split into small, independent services. Each owns its own business domain, its own database, and is deployed independently. They communicate via APIs or message queues.
How it works: A client hits an API Gateway, which routes to the right service. User Service handles auth, Order Service handles orders, Payment Service handles transactions, Inventory Service tracks stock. Each is a separate deployable unit with its own team.
Real-world example: Netflix, Amazon, Truecaller, SmartNews. Every major tech company at scale runs microservices.
Advantages: Independent deployment. Ship the Payment Service without touching User Service. Independent scaling. If Payment is the bottleneck, scale only that. Technology freedom. Fault isolation. If Inventory crashes, Orders still work.
Disadvantages: Distributed system complexity, network failures, latency, partial failures. Data consistency is hard since each service owns its own database. Operational overhead. You now manage 20 services instead of 1.
The hidden cost: Microservices trade code complexity for operational complexity. You need mature DevOps, monitoring, and tracing to succeed.
Interview and blog angle: Microservices are not a silver bullet. They are a trade-off. You gain scalability and team autonomy, you lose simplicity and consistency guarantees.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.