Services

Resources

Company

Monolithic architecture (monolith)

A monolithic architecture puts all of an application's features, such as orders, payments, search and user accounts, into one codebase that is built and deployed as a single unit. Modules call each other in-process and usually share one database. It is the default shape of most applications when they start.

How it works

Everything ships together: one build, one artifact, one deploy. Calls between modules are function calls rather than network requests, so they are fast and easy to trace, and a single database transaction can span several features.

The cost shows up as the system grows. A one-line fix to search ships the whole application. To handle 10 times more checkout traffic you run 10 copies of everything, including the parts that are idle.

Why it matters in production

A monolith is not a mistake; it is often the right starting point because it is simple to build, test and run. Teams split out services when one part needs its own scaling, its own release pace or its own team, and the split usually follows team boundaries, as Conway's law predicts.

See also

On the One2N blog

References

  1. MonolithFirst (Martin Fowler)

Comic about monolithic architecture: Kai's one line change to orders ships the whole shop app, whose modules call each other in process and share one database; on sale day 10 times more orders traffic means 10 copies of everything with the other modules idle; Noor splits out only orders as its own service, accepting a network call and the lost shared transaction while the rest stays a monolith.