Splitting the app

So far in this module, every problem has been about data. This last one is about people.

Three years ago, Tiffin had six engineers and one codebase. Today it has 90 engineers in 12 teams: ordering, payments, rider dispatch, restaurant tools, search, growth and more. They all still work in the same codebase, deploy the same app, and share the same database. The servers are fine. The database is fine. And yet shipping anything has become slow and stressful.

What it feels like

Here is a normal Tuesday at Tiffin:

• The payments team wants to ship a fix for a card provider's new error code. Their change is ready at 10am. It goes out at 4pm, because it's queued behind 23 other changes in the one daily deploy.
• At 4:20pm, the deploy is rolled back. A change from the growth team broke the referral page. The payments fix is rolled back with it.
• The dispatch team wants to try a new rider-matching algorithm. To be safe, they need someone from ordering to review it, because it touches the orders table that ordering also owns. That person is on leave.
• The test suite takes 50 minutes and fails randomly once in every five runs, so everyone reruns it until it passes.
• A memory leak in the restaurant analytics code crashes the server process. Ordering goes down with it, at dinner time.

None of these are about load. They're about too many people changing one thing. Engineers call this a coordination cost: the time spent waiting for, checking with and recovering from each other.

Why it gets worse with size

With 6 engineers, everyone knows the whole codebase and talks to everyone. With 90, nobody knows all of it, and the number of people who might break your change grows much faster than the team.

The rough maths: the number of possible pairs of people who might need to coordinate is n x (n - 1) / 2. Six people make 15 pairs. Ninety people make 4,005. Teams don't talk to every other team, but the shared codebase means any change can affect anyone, so in practice you end up adding process: review rules, deploy queues, change freezes. Each one is reasonable. Together, they slow everyone down.

Past a certain size, the limit on how fast you ship is not your servers. It's how much teams have to coordinate to change anything.

Conway's law

In 1968, Melvin Conway observed that organisations tend to design systems that copy their own communication structure. The joke version that gets passed around: if four teams build a compiler, you get a four-pass compiler.

It works the other way too, and that's the useful part. If you want teams that can work independently, the system needs parts that can change independently. If payments, dispatch and ordering share one codebase, one database schema and one deploy, those teams can't be independent, however you draw the org chart.

So when Tiffin "splits the app", the real goal is not technical. The goal is to give each team a part of the system it can change, test and ship without waiting for anyone else.

Step one: split the code, not the deployment

The first move is not microservices. It's drawing clear lines inside the existing app.

A modular monolith is one deployable app whose code is divided into modules with clear owners, and where modules talk to each other only through defined interfaces.

For Tiffin, that might look like this:

%% caption: One app, one deploy, but each module has an owning team and a public interface. Other modules can't reach into its tables or internals.
flowchart TD
  subgraph app ["Tiffin app: one process, one deploy"]
    O[Ordering module] -- "charge(orderId, amount)" --> P[Payments module]
    O -- "assignRider(orderId)" --> D[Dispatch module]
    R[Restaurants module] -- "menuChanged(restaurantId)" --> S[Search module]
  end

Concretely, that means:

• Folders with owners. src/payments/ belongs to the payments team. A CODEOWNERS file makes their review required for changes there.
• A public interface per module. Ordering calls payments.charge(orderId, amount). It doesn't import payments' internal classes or query the payments tables directly.
• Table ownership. Each table belongs to one module. Only that module reads and writes it. Others ask through the interface.
• Enforced boundaries. A lint rule or build tool fails the build if ordering imports from payments/internal. Without enforcement, boundaries erode within months.

This solves more than you'd expect. Reviews stop needing the whole company. Tests can run per module. Teams understand their part deeply. Shopify's main Rails app, one of the largest in the world, has been organised this way on purpose for years rather than split into services.

What it doesn't solve: there's still one deploy, one test pipeline and one process. A memory leak in analytics still takes down ordering.

Step two: pull out what needs its own life

Some modules have a good reason to run as a separate app, with its own deploy and often its own database. That's a service. Common reasons:

Notice that "it's cleaner" isn't on the list. Each service you split out adds network calls that can fail, data that lives in two places, and a new thing to deploy, monitor and debug. Splitting out a service should solve a problem you can name.

Giving a module its own database is a step you can take on its own, even before it becomes a separate service. The sharding lesson covers this split by function, called federation, and why it usually comes long before sharding.

Signs it's time, and signs it isn't

Good signs:

• Teams regularly wait for each other's changes to ship.
• One part of the app needs to scale or fail independently of the rest.
• Module boundaries already exist and are respected, so you know where the lines are.

Bad signs:

• "Microservices are what big companies do."
• The team is small enough to sit at one table.
• Nobody can say where the boundaries should be. If you can't draw them inside one codebase, splitting it across the network will make things worse, not better.

That last one is the trap. A badly split system, where every request crosses five services and every feature needs four teams to deploy in a precise order, is called a distributed monolith. It has all the costs of microservices and none of the independence. It's worse than what you started with.

Where this goes next

This lesson is the "why" and the first step. The "how" is a whole module. Module 11 covers it: why most systems should start as one app, how to draw service boundaries, how services call each other, API gateways, finding services on the network, and tracing a request across many of them. Its lab picks the first service to carve out of Tiffin.