Should You Start with Microservices? Lessons from Two Real‑World Scenarios

1. Not Starting with Microservices

Imagine working on a large e‑commerce platform that has a product‑listing page and a checkout page. The CTO, John, reads about microservices and decides to split the product‑listing domain and the checkout domain into separate services, giving each team its own goals, KPIs, and SLAs.

Each team can focus on its own area—checkout can run A/B tests and holiday themes, while the product team can optimize recommendations—without worrying about breaking the other domain, as long as the inter‑service APIs remain backward compatible.

When a big promotion arrives, both services can be scaled independently. However, when the CEO, Jane, wants to display related products on the landing and checkout pages, the two teams must share code, design, and logic, making coordinated changes more complex than in a monolith.

Because the front‑end and back‑end of both pages belong to different services, any change must be reflected in both, often requiring duplicated API redesigns and slowing iteration.

In a microservice architecture, internal changes become easier while cross‑service changes become harder.

Since we cannot predict business needs six to twelve months ahead, the article argues that we should never start with microservices.

2. Starting with Microservices

Reversing the story, John now believes microservices are a disaster. He insists on a monolith for a “Buy Now!” button, which ends up as a one‑click checkout method embedded in the Product class:

class Product {
    public void CheckoutWithOneClick() {
      this.PaymentService.Pay(this.Price);
    }
}

This design is a classic code smell. Six months later, every checkout‑related change becomes painful: applying promo codes, handling privileged customers, or implementing complex checkout flows all require touching the monolithic Product class.

When a new CTO arrives, they realize that the one‑click logic is tightly coupled with the regular checkout flow, making refactoring costly.

The new CTO concludes that John should have started with microservices so that the product‑listing team would not own the one‑click logic, preventing the entanglement.

3. The Value of Microservices

Microservices are fundamentally a management tool. They block certain types of changes while making others easier. In the first story, the architecture prevented needed changes; in the second, the lack of microservices caused unwanted complexity.

The key is that architectural choices must align with business growth. A microservice for checkout allows the checkout team to release features independently, use any language, and scale autonomously.

Technical advantages—such as independent scaling, multi‑language implementation, and process‑level isolation—can also be achieved with a monolith, but microservices reduce the need for heavy governance processes.

Ultimately, the decision to adopt microservices should be driven by whether the organization’s growth model benefits from independent service ownership and rapid, isolated releases.