Why Microservices? Designing Scalable Backend Architecture with Scale Cube

Background

When developing server‑side enterprise applications, the system must support various client types—desktop browsers, mobile browsers, and native mobile apps—expose APIs to third parties, and integrate with other applications via Web Services or message brokers. The application processes HTTP or message requests by executing business logic, accessing databases, exchanging information with other systems, and returning HTML/JSON/XML responses.

The application typically follows a layered or hexagonal architecture composed of several component types:

Presentation components that handle HTTP requests and return HTML or JSON/XML (for web service APIs).

Business logic that implements core domain functionality.

Data‑access logic that interacts with databases via DAOs.

Integration logic such as messaging layers (e.g., Spring Integration).

Problem

What is the deployment architecture for such an application?

Requirements

A dedicated development team must own the application.

New team members need to onboard quickly.

The application should be easy to understand and modify.

Continuous deployment must be supported.

Multiple instances should run on many machines to satisfy scalability and availability.

The solution should allow the use of various new technologies (frameworks, languages, etc.).

Solution

Apply the Scale Cube method—particularly Y‑axis scaling—to design the architecture, breaking the application into a set of cooperating services, each responsible for a specific, related set of functions (e.g., order‑management service, customer‑management service).

Service communication can use synchronous protocols like HTTP/REST or asynchronous ones like AMQP.

Each service can be developed and deployed independently.

Every service owns its own database, ensuring decoupling; data consistency across databases can be maintained via replication or application‑level events.

Example

Consider an e‑commerce system that receives customer orders, validates inventory and credit, then ships the order. The system includes a StoreFront UI and backend services for credit checking, inventory management, and order dispatch. The application is deployed as a collection of services.

Result

The solution offers several advantages:

Microservices are small, making them easier for developers to understand, speeding up IDE performance, and reducing container startup time.

Each service can be deployed independently, simplifying frequent releases.

Scalable development: multiple small teams (e.g., “two‑pizza” teams) can own individual services and work autonomously.

Improved fault isolation: a failure in one service does not affect the others.

Teams can use different technology stacks per service.

However, the approach also introduces drawbacks:

Developers must handle the added complexity of distributed systems, including limited IDE support, more difficult testing, and the need for inter‑service communication mechanisms.

Deployments become more complex, especially in production environments with many service types.

Higher memory consumption: running N × M service instances (each with its own JVM or VM) incurs significant overhead compared to a monolith.

Choosing the right time to adopt microservices is challenging. Early‑stage applications often do not need the overhead of a distributed architecture, and startups may prioritize rapid iteration over the scalability benefits of Y‑axis decomposition.

Service decomposition strategies include:

Verb‑oriented services (e.g., a “shipping” service for order fulfillment).

Use‑case‑oriented services (e.g., a “login” service).

Noun‑oriented services that manage specific resources (e.g., an “inventory” service).

Ideally, each service should have a single responsibility, following the Single Responsibility Principle (SRP) advocated by Bob Martin. Unix tool design philosophy—building small, single‑purpose utilities that can be combined—also provides guidance for service design.

Related Patterns

Common microservice patterns include:

Monolithic architecture as an alternative.

API Gateway for client access.

Client‑side and server‑side service discovery.

Message‑based communication and remote procedure call patterns.

One‑service‑per‑host and multiple‑services‑per‑host deployment strategies.

One‑database‑per‑service pattern.

Microservice chassis that provides cross‑cutting concerns.

Known Cases

Large websites that migrated from monoliths to microservices include Netflix, Amazon, and eBay.

Netflix runs a massive SOA architecture handling over 30% of internet traffic, processing billions of video‑stream API calls daily across hundreds of devices.

Amazon.com evolved from a two‑tier architecture to a hundreds‑of‑services SOA, with each web page requiring calls to 100–150 services.

eBay.com transitioned to an SOA where independent applications handle specific business functions, using X‑axis, Y‑axis, and Z‑axis scaling for both application and database layers.

English reference: http://microservices.io/patterns/microservices.html

Original source: http://blog.csdn.net/xn_sung/article/details/52318956