Say Tiffin has decided to split its app into services. The first question isn't which framework, or REST versus gRPC. It's where to cut. Draw the lines well and each team can change its service on its own. Draw them badly and every feature needs four services and four teams to change together.
This lesson is about drawing those lines: what to split by, how to tell a good boundary from a bad one, and the rule that matters most, which is that each service owns its own data.
Don't split by technical layer
The most tempting split is by layer: a "frontend service", an "API service", a "business logic service", a "database service". It's how many apps are already organised in folders, so it feels natural.
It's also the worst split. Think about adding a "schedule an order for later" feature to Tiffin. It needs a new field in the UI, a new API parameter, new logic and a new column. With a layered split, that's a change to every service, deployed in a careful order. You've added network calls between the layers and gained no independence at all.