Avoid These Common Microservice Pitfalls: Granularity, Trend‑Chasing, and Contract Traps

Six: The “Rebel Without a Cause” Developer Trap

The name references the film “Rebel Without a Cause,” describing developers who make wrong decisions based on incorrect reasons when designing microservices.

6.1 Making the Wrong Decision

When testing reveals that services are split too finely, performance suffers due to increased communication overhead and reduced stability; developers may merge them into a coarser service, which seems reasonable but impacts deployment, change control, and testing.

Conversely, when a service is too coarse, testing and deployment become difficult, prompting a split into smaller services.

Thus, overly fine granularity raises communication costs and reliability risks, while overly coarse granularity hampers testing and deployment; architects must balance these trade‑offs.

6.2 Understanding Business Drivers

Designing microservices should start by answering three questions:

Why design a microservice architecture?

What are the primary business drivers?

What is the most important architectural characteristic?

Key characteristics such as deployability, performance, robustness, and scalability guide how services are split or merged.

Scenario 1: Fast deployment is the main goal

When rapid rollout is prioritized, a slightly finer granularity is acceptable.

Scenario 2: Improving performance and robustness is the main goal

When reliability and performance drive the migration, a coarser granularity is preferred.

Teams often discuss service boundaries on a whiteboard, as shown in the diagram.

Seven: The Trend‑Chasing Trap

Blindly adopting microservices because they are fashionable, without analyzing business needs, organizational structure, or technical environment, leads to the “follow‑the‑crowd” trap.

7.1 Pros and Cons of Microservices

Advantages

Easy to deploy

Easy to test

Change control: easier to modify a service’s functionality

Modular

Scalable

Disadvantages

Team organization changes

Performance overhead

Reduced reliability

Increased operational complexity

7.2 Other Architectural Models

Microservices are not the only architectural style; alternatives include:

Service‑Based Architecture

Service‑Oriented Architecture

Layered Architecture

Microkernel Architecture

Space‑Based Architecture

Event‑Driven Architecture

Pipeline Architecture

Systems can mix multiple architectural patterns as needed.

Eight: The Static Contract Trap

Service contracts (XML, JSON, Java objects) define inputs, outputs, and operation names, but they may evolve over time, leading to versioning challenges.

8.1 Header‑Based Versioning

One approach places the version number in the request header (e.g., MIME type) for protocols such as REST, SOAP, AMQP, JMS, MSMQ, etc.

Example using a REST request with a MIME type that encodes the contract version:

POST /trade/buy
Accept: application/vnd.svc.trade.v2+json

8.2 Schema‑Based Versioning

Another method embeds the version directly in the contract schema, making it protocol‑agnostic.

Sample JSON schema with a version field:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "properties": {
    "version": {"type": "integer"},
    "acct": {"type": "number"},
    "cusip": {"type": "string"},
    "sedol": {"type": "string"},
    "shares": {"type": "number", "minimum": 100}
  },
  "required": ["version", "acct", "shares"]
}

This approach avoids protocol dependence but requires each message to be parsed for the version, which can add overhead and complicate automatic mapping to Java objects.