In a monolithic application, all the business logic, UI, and data-access code are compiled and deployed together as one running program. What does 'shared process and memory' mean for how components inside that application call each other, compared to components that live in separate services?

## One artifact, one process A monolithic architecture packages an application's entire codebase — UI, business logic, data access — into a single deployable artifact (one JAR, WAR, or binary) that runs as a single operating-system process at runtime. Everything that artifact contains shares one memory space (heap and stack) and one instance of the language runtime. That single fact drives almost everything distinctive about monoliths, both good and bad. ## How a call between modules is resolved Mechanically, when one module's code invokes another module's function inside a monolith, the language runtime resolves it as an ordinary **in-process call**: - a jump or virtual-dispatch instruction; - arguments passed by reference or value on the stack or heap; - a return address pushed for when the callee finishes. Both caller and callee already agree on memory layout, type representation, and calling convention because they were compiled together. ## Contrast with a call across a network Contrast that with a call between two independently deployed services. The caller must: 1. serialize its arguments into a wire format (JSON, protobuf); 2. open or reuse a socket; 3. transmit bytes across a network stack; 4. have the callee deserialize and validate them; 5. reverse the whole process for the response — plus handle the new failure modes a network introduces (timeouts, partial failures, retries, out-of-order delivery). The monolith simply doesn't have that layer: a call either succeeds by returning normally or fails by throwing an exception that propagates up the same call stack. ## Why the model exists at all This shared-memory model exists because, historically, it is simply the default way software gets built: one team writes one codebase, a compiler or interpreter turns it into one artifact, and that artifact runs as one process on one or more identical machines. It sidesteps an entire category of distributed-systems concerns — service discovery, network partitions, eventual consistency, distributed tracing — that only appear once you split an application across process or network boundaries. For a large class of applications, especially early in a product's life, this is the right trade: you get the benefits of a distributed system (partition tolerance, independent scaling, polyglot tech per service) only when you actually need them, and until then those benefits are pure overhead. ## The upside of shared memory The upside of shared memory is concrete **productivity**: - A single `@Transactional` block (or equivalent) can span multiple 'modules' and commit atomically against one database connection, because there's truly one transaction manager in one process talking to one connection pool. - **Debugging** is a single stack trace instead of a distributed trace stitched across service logs. - **Refactoring** across a module boundary is a compiler-checked, IDE-assisted operation — rename a method and every caller updates — rather than a coordinated, versioned change across independently deployed services. - **Local development** is a single process to run and a single debugger to attach. ## The downside is the same coupling The downside is the same coupling working against you. Shared memory means there is no structural barrier stopping the billing module from directly instantiating and mutating a class that 'belongs' to the inventory module; only code review, package-private visibility, or architectural discipline (e.g., ArchUnit-style rules) enforces a boundary that, in a real distributed system, would be enforced by the network itself — you literally cannot call a private method on a service you can't reach. Over time, without active discipline, cross-module references accumulate into a 'big ball of mud' where nobody can change one part without understanding the whole. And because everything shares one process, **failure isolation collapses**: - A memory leak in a rarely used reporting feature raises heap pressure until the JVM triggers an `OutOfMemoryError` that kills checkout and every other in-flight request too. - A single unhandled exception on a background thread can, in some runtimes, crash the entire process. - A synchronous call to a slow third-party API from one module can exhaust a shared thread pool and starve requests belonging to completely unrelated modules — a classic 'noisy neighbor' failure that shows up in production as unrelated features going down together with no obvious common cause until someone traces it back to shared process resources. ## A concrete example A concrete example: a Spring Boot application with `order`, `inventory`, and `billing` packages all compiled into one `app.jar`. `OrderController` calls `inventoryService.reserve(orderId)` as a plain Java method call, and both participate in the same `@Transactional` method backed by one `DataSource`, so an order write and an inventory decrement commit or roll back together with zero extra coordination code. That same guarantee across independently deployed order and inventory services would require a saga, an outbox pattern, or a distributed transaction coordinator — meaningfully more code and operational complexity to get the same atomicity the monolith gets for free from shared memory.