Monolithic Architecture
A monolithic architecture packs the whole application into one codebase and one deployable unit. Components talk in-memory or through an internal API. There’s no network boundary between parts of the app. From ECE459 L10.
Why start here?
Monoliths are simple to reason about, deploy, and debug. Calls are cheap because there’s no network hop. Traces stay local, so a profiler shows you the whole thing.
L10's advice
Start with a monolith. Only break things off into microservices if that proves valuable later. Medium-to-large companies usually end up with a mixture, not a pure form of either.
Does not scale with team or feature count
Adding functionality means rebuilding and redeploying the whole app. Tight coupling makes local changes risky. One buggy module can take down the whole process.
How does this apply to robotics?
The best performance comes from tight coupling on the same process. For real-time-critical paths (perception → planning → control), a monolithic core may be the right call.
The tradeoff shows up as the system grows. If every component is a thread in one process, a single crash takes down the whole stack. Debugging gets painful fast.
So monolithic for the hot loop, modular for everything else.
Resource: Atlassian on microservices vs monoliths