Microservices
Microservices
What are microservices?
- Splitting a big app into small services
- Develop and deploy each feature independently
- More scalability and flexibility, more complexity
The first thing that changes when you adopt microservices isn't the code but the unit of deployment and the boundaries of accountability. In a monolith, changing a single line meant rebuilding everything and releasing it during an overnight maintenance window. Once services are split, each team deploys its own service on its own schedule. The blast radius of failures changes too: even if the notification server goes down, orders keep coming in. Ultimately, it is less about changing the architecture than about changing how the organization works.
Where you draw the boundaries decides success or failure. In practice, you split by business domain, not by technical layer, and size each service so that one team (usually 5–9 people) can own it end to end. Each service normally gets its own database, so a lookup that once took a single SQL query becomes API calls and event delivery, and you have to accept eventual consistency, where data syncs a few seconds later instead of instantly. If you split only the surface and share a database, it is no different from a traditional SOA or a modular monolith.
It isn't free. Beyond about 10 services, without container orchestration, centralized logging, distributed tracing, and an on-call rotation, you can't even find the cause of an outage. So for an organization with around 10 developers or only 1–2 deployments a month, a well-modularized monolith is much faster. Real migrations also rarely happen all at once; the usual approach is to peel off one feature at a time, starting with those that see heavy traffic or frequent changes.
The most common misconception is that the more you split, the better. If services call one another in long synchronous chains, you end up with a distributed monolith, where deployments still have to happen together and failures still spread. If one order requires seven services to respond in sequence, then even at 99.9% each, overall success drops to 99.3%, and the moment one service slows down, waiting calls pile up into a cascading failure. Work out how operating costs grow with every split before you begin.
Ilyoung JungExpert in smart factories, equipment management, and the Fourth Industrial Revolution
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building it liveAn architecture pattern popularized in the early 2010s, when large-scale web services such as Netflix and Amazon adopted it to overcome the limits of monoliths.
Consider a hypothetical case: Company A, an online food distributor with 240 employees and annual revenue of around KRW 120 billion (≈ US$89,780,000). It had 28 developers, but its system was a 10-year-old monolith, so deployments were possible only during the weekly early-morning maintenance window, and when payments backed up during holiday sales, even the product browsing screen froze entirely. Here is how its nine-month transition unfolded.
- The CTO opened three months of outage reports and said, “Last year, 11 of our 14 hours of downtime started with payment delays.” The whole team agreed the cause was structure, not code.
- The architect set aside the draft to split everything and separated out only four frequently changing services first: orders, payments, inventory, and notifications. Settlement and the admin screens stayed in the existing monolith.
- When the team tried to split the inventory DB into its own service, the logistics lead objected: 'Who is accountable if the counts don't match?' They settled on handling stock deductions through events, with a reconciliation batch running twice a day.
- Two months into the transition, incidents actually rose from 6 to 11 per month, and only after the infrastructure lead added distributed tracing and centralized logging did the average time to find a root cause drop to about 40 minutes.
- Nine months later, deployments had risen from once a week to 14 a week, mean time to recover fell from 52 to 11 minutes, and by scaling up only the order service 8x during the holidays, the company cut server costs by 31% year over year.
- Large scale, heavy traffic, multiple teams
- You need to deploy and scale each service independently
- You use different tech stacks for different parts
- Small startups and early-stage products
- You lack operations staff or automation
- Simple apps (a monolith is faster)