Delivery in10 minutes
Home · Indiranagar, BLR-07
milk, bread, eggs
Your basket
Total₹184
one process · one deploy
Delivery in10 minutes
Home · Indiranagar, BLR-07
milk, bread, eggs
Your basket
Total₹184
The same Zepto order, built two ways. Then ship a fix, crash Payment and survive a sale.
Start with a monolith. Split out a service when one part needs to ship, fail or scale on its own, and a team is ready to own it.
| Difference | Monolith | Microservices |
|---|---|---|
| Deploy | The whole app, every time | Each service on its own |
| Scale | Copy the whole app | Copy only the busy service |
| When one part fails | It can take the whole process down | The rest keeps working; callers need timeouts and retries |
| A call between parts | A function call: fast, can’t get lost | A network call: slower, can time out or fail |
| Data | One database, shared by every module | Each service owns its database |
| One change across parts | One database transaction | A saga: steps with undo, like Zepto’s reserve → charge → create order |
| Teams | One codebase everyone works in | A team owns a service, end to end |
| Pick it when | Starting out, small team, finding the product | Parts need to ship, fail or scale apart, and teams can own them |
One Zepto order, built two ways. On the left, a monolith: one app and one database. On the right, microservices: separate services, each with its own database. Let’s put both through four situations.
First, placing an order. In the monolith, the order goes into one app.
Checkout calls Inventory to hold the items, Payment to charge the customer, and Orders to save it.
Each one is a function call inside the same app: instant, and it can’t get lost.
Then one database saves everything in a single transaction. All of it, or none of it.
Now the same order with microservices.
It comes in through the API gateway to the Checkout service.
Checkout asks Inventory to hold the items.
That’s a network call, and Inventory saves it in its own database.
Payment charges the customer and records it in its own ledger.
And Order saves the order in its own database.
Four databases means no single transaction. Checkout runs a saga instead: if a step fails, the earlier steps are undone.
Next, shipping a fix. A developer changes one line in Payment.
In the monolith, the whole app is rebuilt and restarted, so every module ships again.
With microservices, only the Payment service is redeployed. The other four keep running.
Then, a crash. A bug takes down Payment, and because it runs inside the same app, the whole monolith goes down with it.
A shopper who only wants to search for milk gets an error. Search is down too.
With microservices, only the Payment service goes down.
Search is a separate service, so the results still come back. Only paying waits for Payment to recover.
Finally, the 8 pm sale. The monolith has restarted, and search works again.
Search traffic jumps ten times. A monolith scales as one piece, so we run three copies of the whole app, including parts that didn’t need it.
With microservices, we scale only Search: three copies of Search, and one of everything else.
So which should you pick? Start with a monolith: it’s simpler to build and run. Split out a service when one part needs to ship, scale or stay up on its own, and a team is ready to own it.