When to use microservices, and when one app is better

SeatJaldi has raised ₹40 crore from investors, its Series A, and 40 engineers now work in the Baner office. A payment screen fix is tested and ready. It cannot go live.

All 40 engineers change one codebase, all of the app’s code, deployed as a whole. A reports page change broke this week’s deploy, so everything waits. Meera Kulkarni frowns. “A reports bug is holding up a payment fix? Why are they even connected?”

Arjun Nair draws 20 boxes, one per feature. “Microservices fix everything,” he says. Zoya Mirza asks calmly: “What happens to the booking when the network between two of these is slow for a minute?” Nobody answers. Zoya picks up the eraser.

Use microservices when teams block each other’s deploys or parts need very different scaling; until then, one well-split app is usually cheaper and safer.

You have seen this when a booking site shows the same small bug for weeks after you reported it. Often the whole site goes live as one package, so a small fix waits for the next big deploy.

Each of Arjun’s boxes would be a service.

Or a food app’s cart works while “track my order” says “not available right now”. One service is down; the rest keep answering.

Anything you deploy as a whole is a deployable. Keep one line in your head: split along teams and data, only when one deployable hurts more than the network will.

• Teams: split when one team keeps waiting on another team’s deploy.
• Data: a split piece owns its data; whatever must change in one step stays together.
• Network: every split turns a call inside one program into a network call that can be slow or fail.

There is a middle road. A module is a part of the code with one job.

So, does the team get faster with 20 services? Not by itself: twenty services means twenty deploys to watch and a network call wherever two of them talk. Zoya’s picture keeps three.

A modular monolith is one deployable app whose modules own their data and talk only through agreed doors.

In the kitchen, it is one stove with a rota and a labelled shelf per aunty. An aunty who moves out takes her shelf in one piece.

Three costs: network calls that can be slow or fail, more things to deploy and watch, and split data.

• Network: sabzi on the next shelf was free; now it is a phone call, and the neighbour may be out. Each call needs a timeout, few retries at one layer only, and a fallback.
• Running it: three kitchens, three cylinders. Each service has its own servers, deploys and alerts.
• Data: a booking and its payment in two databases cannot share one transaction.

Split along team and data boundaries one piece at a time, and keep together anything that must change in one step.

• Team: does one team own this code?
• Data: can it own its tables, with nobody else reading them?
• Deploy: can it go live alone?
• One step: does it share a write with another piece? Then they stay together.

Lift out one piece and leave the rest running. It is like one aunty moving to her own flat while the kitchen keeps cooking. Engineers call this the strangler fig approach, after a vine that slowly replaces the tree it grows on.

Now one booking crosses two databases, and no single transaction can hold both. SeatJaldi uses a saga.

1. 1

   Hold the seat

   Booking holds seat A12 in the session store.

2. 2

   Take the money

   Payments charges ₹299. If that fails, the undo releases the hold.

3. 3

   Mark it sold

   Booking marks A12 sold in one transaction, as in lesson 14. If that fails, booking retries it; if it still cannot, the undos run backwards: refund the ₹299, then release the hold.

In the kitchen, a saga is borrowing sabzi from the next flat with a promise to bring it back if dinner is cancelled. Each step and undo must be safe to run twice, so each carries an idempotency key. Between steps, others can see the half-done state, which is why the seat is held first.

A chain is when booking calls payments, and payments calls another service, before anyone answers, so their downtime adds up. Say each is up 99.9% and fails on its own (assumptions). A 30-day month has 43,200 minutes, as in lesson 28.

• One app: 0.001 × 43,200 = about 43 minutes down a month.
• Five in a chain: 0.999 to the power 5 = 0.995, so 0.005 × 43,200 = about 216 minutes, 3.6 hours.
• Speed: a round trip inside a data centre is roughly 0.5 ms (an order of magnitude). Five calls in a row add at least 2.5 ms.
• Retries: lesson 26’s sum. Three tries at each of 5 services turn one request into 3 to the power 5 = 243 calls on the last one.

Events break the chain. Booking publishes an event and answers without waiting, so a down notifications service only delays the SMS. Save the event in the same transaction as the booking, or a crash between the two loses it.

What just happened? The event holds ids and facts, not the whole booking; notifications never reads the booking database. If the event arrives twice, the worker must be idempotent.

Try it yourself

1. 1

   List six modules

   For a tiffin app or SeatJaldi, list six modules with their owner team and data.

2. 2

   Mark the split

   Mark the one with the best reason to split: its own team, a different load or risky deploys.

3. 3

   Mark what stays

   Mark modules that must change data together in one step.

4. 4

   Draw the doors

   Write one API call and one event that connect the split piece back.

5. 5

   Slow it down

   In a test setup, slow the split piece by ten seconds. Write what the user should see.

6. 6

   Check your answer

   Right if the split piece owns data nobody else reads and the one-step modules stayed together. You also named the network failure you added and your fix: a timeout, a retry or a fallback.

Back at the whiteboard, Zoya rubs out 17 of the 20 boxes. Three are left: the booking modular monolith, payments and notifications. “Teams and data first,” she says. “Network last.”

Payments gets its own team and database; notifications scales alone. Booking stays together, because the seat check and write are one step. And a slow network to payments? Booking times out, holds the seat and shows “payment pending”.

Two aunties got their own flats; the rest kept one kitchen with labelled shelves. The payment fix goes live alone. Meera looks at the new boxes and asks, “Step back: how did SeatJaldi get from one ₹1,200 server to 1 crore users?”