KCNA — Microservices Architecture

3 minute read

Microservices Architecture

Microservices architecture is fundamental to cloud-native design and is frequently tested in the KCNA exam.

Monolith vs Microservices

Monolithic Architecture

A monolith is a single application where all components are tightly coupled and deployed as one unit.

┌─────────────────────────────────┐
│         Monolithic App          │
│  ┌──────┬──────┬──────┬──────┐ │
│  │ Auth │ Cart │Order │Payment│ │
│  │      │      │      │      │ │
│  └──┬───┴──┬───┴──┬───┴──┬───┘ │
│     └──────┴──────┴──────┘     │
│         Shared Database         │
└─────────────────────────────────┘

Microservices Architecture

Microservices decompose the application into small, independently deployable services, each owning its own data.

┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐
│  Auth  │  │  Cart  │  │ Order  │  │Payment │
│Service │  │Service │  │Service │  │Service │
└───┬────┘  └───┬────┘  └───┬────┘  └───┬────┘
    │           │           │           │
┌───┴────┐  ┌──┴─────┐  ┌──┴─────┐  ┌──┴─────┐
│Auth DB │  │Cart DB │  │Order DB│  │Pay DB  │
└────────┘  └────────┘  └────────┘  └────────┘

Comparison

Aspect Monolith Microservices
Deployment All-or-nothing Independent per service
Scaling Scale entire app Scale individual services
Technology Single tech stack Polyglot — each service can use different tech
Data Shared database Database per service
Team Large team on one codebase Small teams own individual services
Failure One bug can crash everything Failure is isolated to one service
Complexity Simple to start, complex to grow Complex to start, manageable at scale

Communication Patterns

Microservices need to communicate with each other. There are two primary patterns:

Synchronous (Request-Response)

Services communicate directly via HTTP/REST or gRPC.

User → API Gateway → Auth Service → (response)
                   → Order Service → (response)

Pros: Simple, real-time responses
Cons: Tight coupling, cascading failures if a service is down

Asynchronous (Event-Driven)

Services communicate through a message broker (Kafka, RabbitMQ, NATS).

Order Service → [Message Queue] → Payment Service
                                → Notification Service
                                → Inventory Service

Pros: Loose coupling, failure tolerance, better scalability
Cons: More complex, eventual consistency

API Gateway Pattern

An API Gateway sits between clients and microservices:

                    ┌──── Auth Service
Client → API ──────┼──── Order Service
         Gateway    ├──── Cart Service
                    └──── Payment Service

Responsibilities:

  • Routing: Route requests to the correct microservice
  • Authentication: Validate tokens before forwarding
  • Rate Limiting: Prevent abuse
  • Load Balancing: Distribute traffic across service instances

In Kubernetes, Ingress controllers and API gateways serve this role.

Decomposition Patterns

How do you break a monolith into microservices?

By Business Capability

Each microservice maps to a business function:

  • User Management Service
  • Order Processing Service
  • Payment Service
  • Notification Service

By Subdomain (Domain-Driven Design)

Use Bounded Contexts from DDD to define service boundaries:

  • Each bounded context becomes a microservice
  • Services communicate through well-defined interfaces

Strangler Fig Pattern

Gradually replace monolith components with microservices:

  1. Identify a component to extract
  2. Build a new microservice for it
  3. Route traffic to the new service
  4. Repeat until the monolith is gone

Anti-Patterns

Anti-Pattern Description Problem
Distributed Monolith Microservices that are tightly coupled — must deploy together You get the complexity of microservices without the benefits
Shared Database Multiple services using the same database Changes to one service’s schema can break others
Too Fine-Grained Services that are too small Excessive network overhead and operational complexity
No API Versioning Breaking API changes without versioning Downstream services break on updates

Microservices in Kubernetes

Kubernetes is an ideal platform for microservices:

K8s Feature Microservices Benefit
Pods Run each microservice in its own pod
Services Provide stable networking for service-to-service communication
Deployments Rolling updates and rollbacks per service
Namespaces Isolate services by team or environment
ConfigMaps/Secrets Externalize configuration per service
HPA Scale individual services based on load

KCNA Exam Tips

  • Know the key differences between monoliths and microservices
  • Understand synchronous vs asynchronous communication patterns
  • The Strangler Fig Pattern is a common exam topic for migration strategies
  • Know what a distributed monolith anti-pattern is
  • Remember that each microservice should own its own data

What’s Next?

Learn the twelve-factor methodology — the guiding principles for building cloud-native applications.

Next: Twelve-Factor Apps →

Updated:

You may also enjoy