Part 2 of this course is about systems spread across many machines and many services. So it may seem odd that its first lesson argues for keeping everything in one app for as long as possible.
That's on purpose. Microservices solve real problems, and the rest of this module shows how. But they also create problems that a single app simply doesn't have, and many teams take on those problems years before they need to. Before learning to split a system, you should know what splitting costs.
Two ways to build Tiffin
A monolith is one application, built and deployed as one unit. All of Tiffin's features (menus, ordering, payments, dispatch, notifications) live in one codebase and run in one process. To call payments, ordering makes a function call.
A microservice architecture splits an application into small, separately deployed services, each owning one business capability and its own data, talking to each other over the network.
%% caption: Microservices. Each service is deployed on its own and owns its own data. Calls between them cross the network. flowchart TD O[Orders service]:::hot --> ODB[(Orders DB)]:::store O -- network --> P[Payments service] --> PDB[(Payments DB)]:::store O -- network --> D[Dispatch service] --> DDB[(Dispatch DB)]:::store
The boxes look similar. The difference is the arrows. In the first picture an arrow is a function call. In the second it's a network request, and that changes almost everything.