What a Monolith Really Is

One deployable unit

A monolith is an application built and deployed as one unit: one codebase (or one build), one process type, usually one database. All features, such as catalogue, cart, payments and admin, run in the same process and call each other with ordinary function calls. "Monolith" is not an insult. Monoliths are simple to develop (one repository, one IDE project, easy refactoring across features), simple to test end to end, simple to deploy (one artefact) and simple to operate (one thing to monitor). Calls are fast and transactions are easy: updating an order and its stock happens in one ACID database transaction. They scale fine horizontally when stateless: run ten copies behind a load balancer. Large, successful products such as Shopify and Basecamp have run on well-structured monoliths for many years. The real problem is not the monolith but the big ball of mud, where everything depends on everything.

Inside a monolith

Many features share one process and one database, deployed together.

A request handled entirely in-process

Every step is a function call, and one transaction protects all the writes.

def place_order(customer_id, items):
    with db.transaction():                       # one ACID transaction
        customer = customers.get(customer_id)
        pricing.apply_discounts(customer, items)  # in-process call: nanoseconds
        inventory.reserve(items)                  # fails? whole transaction rolls back
        order = orders.create(customer, items)
        payments.record_pending(order)
    notifications.send_order_email(order)         # after commit
    return order

Ball of mud is the real enemy

Teams that blame "the monolith" usually suffer from missing boundaries: any module reads any table and calls any class. Splitting that into services without fixing boundaries produces a distributed ball of mud, which is worse.

त्वरित जाँच: Which is a genuine advantage of a monolith?

• Operations across features can share one ACID transaction
• Each feature can be deployed independently
• Failures are always isolated per feature
• Each team can choose its own database