Microservices characteristics - Deep Dive

Overview - Microservices characteristics

What is it?

Microservices are a way to build software by splitting a big application into many small, independent parts called services. Each service does one specific job and can work on its own. These services communicate with each other over a network to make the whole system work. This approach helps teams build, update, and fix parts of the application faster and more easily.

Why it matters

Without microservices, software tends to be one big block where changing one part can break others, making updates slow and risky. Microservices solve this by letting teams work on small pieces independently, so new features and fixes happen faster. This means better software quality, quicker delivery, and easier scaling when more users join.

Where it fits

Before learning microservices, you should understand basic software design and how traditional monolithic applications work. After microservices, you can explore related topics like containerization, orchestration tools like Kubernetes, and API design to manage communication between services.

Mental Model

Core Idea

Microservices break a big application into small, independent services that each do one job and talk over a network to work together.

Think of it like...

Imagine a restaurant kitchen where each chef specializes in one dish. Instead of one chef cooking everything, each chef focuses on their specialty and passes dishes to the waiters who serve customers. This way, the kitchen runs smoothly and can handle many orders at once.

┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│  Service A    │◄───►│  Service B    │◄───►│  Service C    │
│ (User Auth)   │     │ (Orders)      │     │ (Payments)    │
└───────────────┘     └───────────────┘     └───────────────┘
       ▲                    ▲                    ▲
       │                    │                    │
   Independent          Independent          Independent
   deployable           deployable           deployable
   services             services             services

Build-Up - 7 Steps

1

Foundation

Understanding service independence

Concept: Microservices are independent units that can be developed, deployed, and scaled separately.

Each microservice owns its own code and data. It runs on its own and does not depend on other services to start or work. This independence means teams can update one service without stopping the whole application.

Result

You can change or fix one service without affecting others, making development faster and safer.

Understanding independence helps you see why microservices reduce risks and speed up updates.

2

Foundation

Single responsibility principle in microservices

Concept: Each microservice focuses on one specific business function or capability.

Instead of one big program doing everything, microservices split tasks like user login, product catalog, or payment processing into separate services. This makes each service simpler and easier to understand.

Result

Services are smaller and focused, which makes them easier to build, test, and maintain.

Knowing that each service has one job clarifies how microservices improve clarity and reduce complexity.

3

Intermediate

Communication between microservices

🤔Before reading on: do you think microservices communicate by sharing memory or by sending messages? Commit to your answer.

Concept: Microservices communicate over the network using messages or APIs, not by sharing memory or databases.

Since services run independently, they use protocols like HTTP or messaging queues to talk. This keeps them loosely connected and allows each to use different technologies if needed.

Result

Services can evolve separately and even be written in different programming languages.

Understanding network communication explains how microservices stay independent yet work together.

4

Intermediate

Decentralized data management

🤔Before reading on: do you think microservices share one database or have their own databases? Commit to your answer.

Concept: Each microservice manages its own database or data storage to avoid tight coupling.

Instead of sharing one big database, each service stores and controls its own data. This prevents changes in one service's data from breaking others.

Result

Data is isolated per service, improving reliability and allowing different storage types per service.

Knowing data decentralization helps understand how microservices avoid data conflicts and improve scalability.

5

Intermediate

Independent deployment and scaling

Concept: Microservices can be deployed and scaled individually based on demand.

If one service needs more resources, like the payment service during sales, it can be scaled up without affecting others. Similarly, updates can be released for one service without redeploying the entire system.

Result

Faster releases and efficient use of resources tailored to each service's needs.

Recognizing independent deployment and scaling shows how microservices improve flexibility and cost-effectiveness.

6

Advanced

Fault isolation and resilience

🤔Before reading on: do you think a failure in one microservice crashes the whole system or only affects that service? Commit to your answer.

Concept: Failures in one microservice are contained and do not bring down the entire application.

Because services are separate, if one crashes or slows down, others keep working. Techniques like retries, timeouts, and circuit breakers help handle failures gracefully.

Result

The system remains available and responsive even when parts fail.

Understanding fault isolation explains why microservices improve system reliability and user experience.

7

Expert

Complexity of distributed systems

🤔Before reading on: do you think microservices simplify or add complexity to system management? Commit to your answer.

Concept: While microservices bring many benefits, they introduce challenges like network latency, data consistency, and monitoring across services.

Managing many services requires tools for service discovery, logging, tracing, and handling partial failures. Developers must design for eventual consistency and handle complex deployment pipelines.

Result

Microservices require advanced infrastructure and careful design to avoid new problems.

Knowing the hidden complexity helps prepare for real-world challenges and avoid naive microservices adoption.

Under the Hood

Microservices run as separate processes or containers, each with its own runtime environment and database. They communicate via network calls using protocols like HTTP/REST, gRPC, or messaging queues. Each service encapsulates its logic and data, avoiding shared memory or databases. Deployment pipelines automate building, testing, and releasing each service independently. Monitoring and logging systems collect data from all services to provide a unified view.

Why designed this way?

Microservices were designed to overcome the limitations of monolithic applications, which become hard to maintain and scale as they grow. By splitting into small, focused services, teams can work independently, deploy faster, and scale only what is needed. The tradeoff is added complexity in communication and management, but the benefits in agility and resilience outweigh these for many systems.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│  Service A    │──────▶│  Service B    │──────▶│  Service C    │
│ (Own DB)     │       │ (Own DB)     │       │ (Own DB)     │
└───────────────┘       └───────────────┘       └───────────────┘
       ▲                      ▲                      ▲
       │                      │                      │
  Independent             Independent             Independent
  runtimes                runtimes                runtimes

Monitoring & Logging System collects data from all services
Deployment pipelines build and release each service separately

Myth Busters - 4 Common Misconceptions

Quick: Do microservices always make systems simpler to manage? Commit yes or no.

Common Belief: Microservices always simplify system management because each service is small and focused.

Reality: Microservices add complexity in deployment, monitoring, and communication that requires sophisticated tools and practices.

Why it matters: Ignoring this leads to overwhelmed teams and unstable systems due to unmanaged complexity.

Quick: Do microservices share one database to keep data consistent? Commit yes or no.

Common Belief: All microservices share a single database to keep data consistent and avoid duplication.

Reality: Each microservice has its own database to maintain independence and avoid tight coupling.

Why it matters: Sharing databases creates hidden dependencies that break the benefits of microservices and cause deployment issues.

Quick: Can a failure in one microservice crash the entire application? Commit yes or no.

Common Belief: If one microservice fails, the whole application usually crashes or becomes unusable.

Reality: Failures are isolated; other services continue working, improving overall system resilience.

Why it matters: Believing otherwise may cause unnecessary fear or over-engineering of fault tolerance.

Quick: Do microservices always use the same programming language? Commit yes or no.

Common Belief: All microservices must be written in the same programming language for compatibility.

Reality: Microservices can use different languages and technologies as long as they communicate properly.

Why it matters: This misconception limits technology choices and prevents teams from using the best tools for each service.

Expert Zone

1

Microservices require careful API versioning to avoid breaking changes when services evolve independently.

2

Event-driven communication patterns can reduce tight coupling but add complexity in ensuring message delivery and ordering.

3

Observability (logging, tracing, metrics) is critical and often underestimated; without it, debugging distributed systems is very hard.

When NOT to use

Microservices are not ideal for small applications or teams because the overhead of managing many services outweighs benefits. Monolithic or modular monolith architectures are better alternatives in such cases.

Production Patterns

Real-world systems use service meshes for secure, reliable communication; CI/CD pipelines for automated deployments; and circuit breakers to handle service failures gracefully.

Connections

Event-Driven Architecture

Builds-on

Understanding microservices helps grasp event-driven systems where services react to events asynchronously, improving scalability and decoupling.

Containerization (Docker)

Supports

Microservices often run in containers, which package each service with its environment, making deployment consistent and isolated.

Human Organizational Structure

Analogy to

Microservices mirror how teams are organized around business capabilities, showing how software design reflects human collaboration patterns.

Common Pitfalls

#1 Trying to share a single database across microservices.

Wrong approach:

Service A and Service B both read and write to the same database tables directly.

Correct approach:

Each service has its own database and communicates changes via APIs or events.

Root cause:

Misunderstanding that data sharing breaks service independence and causes tight coupling.

#2 Deploying all microservices together as one unit.

Wrong approach:

Building and releasing all services in one package, requiring full redeployment for any change.

Correct approach:

Deploying each microservice independently with its own pipeline.

Root cause:

Treating microservices like a monolith, missing the benefit of independent deployment.

#3 Ignoring network failures in service communication.

Wrong approach:

Assuming all service calls always succeed without retries or timeouts.

Correct approach:

Implementing retries, timeouts, and circuit breakers to handle failures gracefully.

Root cause:

Underestimating the complexity of distributed systems and network unreliability.

Key Takeaways

Microservices split big applications into small, independent services that each do one job well.

Each service owns its own data and communicates over the network, enabling independent development and deployment.

This architecture improves scalability, fault isolation, and team agility but adds complexity in communication and management.

Successful microservices require careful design of APIs, data ownership, and robust infrastructure for monitoring and deployment.

Microservices are powerful but not always the best choice; understanding their tradeoffs is key to using them effectively.