Characteristics of a Well-Designed Microservice

A well-designed microservice is small, focused, loosely coupled, independently deployable, resilient, observable, and owns its business capability and data.

1. Single Business Responsibility

A microservice should focus on one specific business capability.

For an E-commerce system:

Product Service   → Product management
Order Service     → Order processing
Payment Service   → Payment processing
Inventory Service → Stock management

A Payment Service should not also contain product or inventory logic.

This follows the idea of high cohesion.

2. Loosely Coupled

Services should have minimum dependency on each other.

Bad design:

Order Service
     ↓
Directly reads Payment DB

Better design:

Order Service
     ↓
Payment API / Event
     ↓
Payment Service
     ↓
Payment DB

The internal implementation of Payment Service can change without forcing Order Service to know those details.

3. Independently Deployable

Each microservice should be deployable independently.

Product Service v1
Order Service   v1
Payment Service v1
        ↓
Payment Service v2

Only Payment Service needs to be redeployed when its internal functionality changes, assuming its external contract remains compatible.

This is one of the most important characteristics of microservices.

4. Independently Scalable

Each service should be scalable based on its own workload.

Product Service
 ├── Instance 1
 ├── Instance 2
 └── Instance 3

Payment Service
 └── Instance 1

If Product Service receives heavy traffic, we can scale Product Service without scaling Payment Service.

5. Owns Its Data

A microservice should ideally own the data related to its business capability.

Product Service → Product DB
Order Service   → Order DB
Payment Service → Payment DB

Other services should normally communicate through the service's API or events, rather than directly modifying its tables.

Important

This doesn't necessarily mean every service requires a separate physical SQL Server. The important principle is clear data ownership and isolation.

6. Clear API Contract

A microservice should expose a clear and stable contract.

For example:

GET  /api/orders/1001
POST /api/orders
PUT  /api/orders/1001

Other services should depend on the contract, not the internal implementation.

When contracts evolve, backward compatibility and API/event versioning should be considered.

7. Autonomous

A good microservice should have as much control as practical over its:

• Business logic
• Data
• Deployment
• Scaling
• Release lifecycle

For example:

Payment Team
     ↓
Payment Service
     ↓
Payment Database
     ↓
Payment Deployment

This reduces coordination between teams.

8. Resilient and Fault Tolerant

In microservices, network and service failures are expected.

Suppose:

Order Service
      ↓
Payment Service
      X
   Unavailable

The Order Service should not wait forever or cause cascading failures.

Common resilience techniques include:

• Timeout
• Retry
• Circuit Breaker
• Bulkhead
• Graceful degradation
• Message queues

For example:

Order Service
     ↓
Payment Service fails
     ↓
Retry / Circuit Breaker
     ↓
Handle failure gracefully

9. Observable

With many services, debugging becomes difficult unless the system provides good observability.

A microservice should provide:

Logs

Order 1001 created successfully
Payment failed for Order 1001

Metrics

Examples:

Request Count
Error Rate
CPU Usage
Response Time

Distributed Tracing

TraceId: ABC123

API Gateway
    ↓
Order Service
    ↓
Payment Service
    ↓
Inventory Service

Tools such as OpenTelemetry are commonly used for distributed tracing and telemetry.

10. Stateless Where Possible

Microservice instances should preferably avoid storing user/session state in the server's local memory.

Bad:

User Session
     ↓
Instance 1 Memory

If the next request reaches Instance 2, the state may not exist there.

Better:

Instance 1 ─┐
Instance 2 ─┼──→ Distributed Store
Instance 3 ─┘

Stateless services are easier to scale horizontally.

11. Secure

Each service should be designed with security in mind.

Typical requirements include:

• Authentication
• Authorization
• HTTPS
• Input validation
• Secret management
• Least-privilege access
• Secure service-to-service communication

A request passing through an API Gateway does not mean internal services can ignore security.

12. Automation Friendly

Microservices should support automated:

Build
  ↓
Test
  ↓
Deploy
  ↓
Monitor

Therefore, good microservices are normally designed around CI/CD and automated testing/deployment.

Advantages of These Characteristics

A properly designed microservice provides:

• Independent deployment
• Independent scaling
• Better maintainability
• Clear business boundaries
• Better team ownership
• Better fault isolation
• Faster independent releases
• Easier replacement or modification of individual services

Disadvantages / Challenges

Achieving these characteristics introduces complexity:

• More deployments
• Network failures
• Distributed transactions
• Eventual consistency
• API versioning
• More infrastructure
• More monitoring requirements
• Harder debugging
• More complex integration testing

Therefore, simply splitting a large application into many Web APIs does not automatically make it good microservices architecture.

Key Points

A well-designed microservice should be:

Easy way to remember

Well-Designed Microservice
        ↓
Focused
Independent
Loosely Coupled
Owns its Data
Scalable
Resilient
Observable
Secure

Interview Questions & Answers

Q1. What are the most important characteristics of a microservice?

A good microservice is business-focused, loosely coupled, highly cohesive, independently deployable, independently scalable, resilient and observable, with clear ownership of its data.

Q2. What does loosely coupled mean?

One service should have minimal knowledge about another service's internal implementation. Communication should happen through well-defined APIs or events.

Q3. Why should a microservice own its data?

It prevents database-level coupling and allows the service to change its internal data model without directly affecting other services.

Q4. Should microservices be stateless?

Where practical, yes. Stateless services are easier to scale horizontally because requests can be handled by any available instance.

Q5. What is the difference between high cohesion and loose coupling?

High cohesion means related functionality stays inside the same service.

Loose coupling means the service has minimal dependency on other services.

Q6. How do you make a microservice resilient?

Common techniques include timeouts, retries, circuit breakers, bulkheads, asynchronous messaging and graceful failure handling.

Q7. How do you monitor microservices?

Using the three major observability signals:

Logs + Metrics + Distributed Traces

Centralized logging and OpenTelemetry are commonly used.

Q8. Is a small Web API automatically a microservice?

No. Size alone doesn't make something a microservice. It should have a meaningful business boundary, independent lifecycle, clear ownership and loose coupling.

Interview One-Line Answer

A well-designed microservice is focused on a specific business capability, loosely coupled, highly cohesive, independently deployable and scalable, owns its data, and is designed for resilience, security and observability.