Microservices Architecture

1. What is Microservices Architecture?

Microservices Architecture is a software architecture style where a large application is divided into multiple small, independent services.

Each service:

• Handles a specific business capability.
• Can be developed and deployed independently.
• Usually owns its own data/database.
• Communicates with other services through APIs or messaging.
• Can be scaled independently.

Simple example

Consider an E-commerce application.

Instead of building everything as one application:

E-Commerce Application
        |
        ├── User Management
        ├── Product Management
        ├── Order Management
        ├── Payment
        ├── Inventory
        └── Notification

With microservices, these become separate deployable services:

                    Client
                       |
                       ↓
                  API Gateway
                       |
       ┌───────────────┼────────────────┐
       ↓               ↓                ↓
 Product Service   Order Service   Payment Service
       |               |                |
   Product DB        Order DB         Payment DB
                       |
                       ↓
               Inventory Service
                       |
                  Inventory DB

For example:

Product Service
   → Product details
   → Product search
   → Product DB

Order Service
   → Create order
   → Track order
   → Order DB

Payment Service
   → Process payment
   → Refund payment
   → Payment DB

These services are independent applications, not simply different folders or classes inside the same application.

2. Why Do We Need Microservices?

As a monolithic application becomes large, several problems can appear.

Suppose we have:

ECommerce.WebAPI
 ├── Users
 ├── Products
 ├── Orders
 ├── Payments
 ├── Inventory
 └── Notifications

Everything is deployed together.

Imagine only the Payment module needs a change.

In a monolith, we may have to:

Change Payment
      ↓
Build entire application
      ↓
Test entire application
      ↓
Deploy entire application

With microservices:

Change Payment Service
        ↓
Build Payment Service
        ↓
Test Payment Service
        ↓
Deploy Payment Service

The other services can continue running without being redeployed.

This becomes particularly useful for large systems with multiple teams and independently evolving business domains.

3. Purpose of Microservices

The main purpose is to break a complex system into small, loosely coupled, independently manageable services.

The key goals are:

Independent Development

Different teams can work on different services.

Team A → Order Service
Team B → Payment Service
Team C → Inventory Service
Team D → Notification Service

Independent Deployment

Changing one service doesn't necessarily require deploying every service.

Payment Service v1
        ↓
Payment Service v2

Order, Product and Inventory services can remain unchanged.

Independent Scaling

Suppose traffic is:

Product Service     → 50,000 requests
Order Service       → 10,000 requests
Payment Service     → 2,000 requests

We don't necessarily need to scale the whole application.

We could scale only Product Service:

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

Payment Service
    └── Instance 1

This is one of the important operational benefits of microservices.

4. How Does Microservices Architecture Work?

Consider an order request.

Customer
   |
   ↓
API Gateway
   |
   ↓
Order Service
   |
   ├────→ Inventory Service
   |
   ├────→ Payment Service
   |
   └────→ Notification Service

A simplified flow might be:

1. Customer places order
          ↓
2. Order Service creates order
          ↓
3. Inventory Service checks/reserves stock
          ↓
4. Payment Service processes payment
          ↓
5. Order status is updated
          ↓
6. Notification Service sends email/SMS

The services may communicate using synchronous APIs or asynchronous messaging.

5. Communication Between Microservices

There are two major approaches.

Synchronous Communication

One service directly calls another and waits for the response.

Common technologies:

• HTTP/REST
• gRPC

Example:

Order Service
      |
      | HTTP
      ↓
Inventory Service
      |
      | Response
      ↓
Order Service

ASP.NET Core might use HttpClient through IHttpClientFactory.

Asynchronous Communication

Services communicate through messages/events.

Common technologies include:

• RabbitMQ
• Azure Service Bus
• Apache Kafka

Example:

Order Service
      |
      | OrderCreated Event
      ↓
 Message Broker
      |
  ┌───┴──────────┐
  ↓              ↓
Inventory     Notification
Service       Service

The Order Service doesn't necessarily wait for all consumers to finish processing the event.

6. Database in Microservices

A core microservices principle is service ownership of data.

For example:

Product Service
      |
      ↓
 Product DB


Order Service
      |
      ↓
 Order DB


Payment Service
      |
      ↓
 Payment DB

Ideally, another service should not directly modify tables owned by a different service.

For example:

Order Service
     |
     X  Direct DB access
     |
Payment DB

Instead:

Order Service
     |
     | API / Message
     ↓
Payment Service
     |
     ↓
Payment DB

This preserves service boundaries and reduces database-level coupling.

Important: "Database per service" means data ownership per service. It doesn't necessarily mean every service must have a completely separate physical database server.

7. Microservices vs Monolithic Architecture

Microservices are therefore not automatically better than a monolith. The architecture is useful when the application's scale, organizational structure, deployment needs, and domain complexity justify the additional distributed-system complexity.

8. Important Components in Microservices

A production microservices system commonly involves:

                 Client
                    |
                    ↓
               API Gateway
                    |
        ┌───────────┼───────────┐
        ↓           ↓           ↓
      Order      Product     Payment
     Service     Service     Service
        |           |           |
        ↓           ↓           ↓
     Order DB   Product DB   Payment DB
        |
        ↓
    Message Broker
        |
    ┌───┴─────────┐
    ↓             ↓
Inventory     Notification
 Service        Service

Typical supporting components include:

• API Gateway
• Load Balancer
• Service discovery where required
• Message broker
• Centralized logging
• Distributed tracing
• Health checks
• Authentication/Authorization
• Configuration and secret management
• Containerization
• Orchestration
• Resilience mechanisms
• Monitoring and alerting

In the .NET ecosystem, technologies might include ASP.NET Core, YARP or Ocelot, Docker, Kubernetes, Azure Service Bus/RabbitMQ/Kafka, OpenTelemetry, and cloud-native monitoring services.

9. Advantages

1. Independent Deployment

One service can be updated without necessarily redeploying the entire system.

2. Independent Scaling

Only heavily used services can be scaled.

3. Smaller Codebases

Each service focuses on a limited business capability.

4. Team Independence

Different teams can own different services.

5. Technology Flexibility

Services can technically use different technologies when there is a valid reason.

Order Service       → .NET
Recommendation      → Python
Search Service      → Java

However, using many technology stacks unnecessarily can increase operational complexity.

6. Fault Isolation

A failure in one service can sometimes be isolated rather than crashing the entire application—provided the system is designed with resilience.

7. Faster Independent Releases

Teams can potentially release their services on separate schedules.

10. Disadvantages

Microservices introduce substantial complexity.

1. Distributed-System Complexity

Instead of:

Method → Method

you may have:

Service
   ↓
Network
   ↓
Gateway / Broker
   ↓
Another Service

Networks can fail, timeout, become slow, or return partial results.

2. Harder Debugging

A single request may travel through several services.

Gateway
   ↓
Order
   ↓
Inventory
   ↓
Payment
   ↓
Notification

Distributed tracing becomes important.

3. Data Consistency Is Harder

One ACID database transaction cannot normally span independently owned services in the same simple way as a monolithic database transaction.

Patterns such as Saga and eventual consistency may be required.

4. Deployment Complexity

You may have dozens or hundreds of independently deployed applications.

5. Network Latency

Remote calls are significantly different from in-process method calls.

6. Monitoring Complexity

You need centralized:

• Logs
• Metrics
• Traces
• Health monitoring

7. Infrastructure Cost

Containers, gateways, brokers, observability systems, orchestration and additional environments can increase operational cost.

11. When Should We Use Microservices?

Microservices can make sense when:

• The application is large and complex.
• Business domains have clear boundaries.
• Multiple teams need independent ownership.
• Different components require different scaling.
• Independent deployments are important.
• The organization has mature DevOps/CI/CD practices.
• High availability and fault isolation are important requirements.

They may be unnecessary for a small application with a small team and simple deployment requirements.

A modular monolith is often a useful alternative when you want strong domain separation without the operational overhead of distributed services.

12. Key Points

For interview preparation, remember these:

• Microservices = application divided into small independent services.
• Each service should represent a business capability/bounded context, not merely a technical layer.
• Services should be loosely coupled and highly cohesive.
• Each service can be developed, deployed and scaled independently.
• Services communicate through REST, gRPC, or messaging/events.
• Prefer service-owned data rather than allowing multiple services to directly manipulate the same tables.
• Microservices enable independent deployment and scaling.
• They introduce distributed-system complexity.
• Important concerns include resilience, observability, security, service communication and data consistency.
• Common patterns include API Gateway, Saga, Circuit Breaker, Retry, Outbox and Event-Driven Architecture.
• Docker/Kubernetes are commonly used with microservices, but microservices do not require containers or Kubernetes.
• Don't choose microservices simply because they are popular; use them when the business and operational requirements justify the complexity.

13. Interview Questions & Answers

Q1. What is Microservices Architecture?

Microservices Architecture divides an application into small, independently deployable services. Each service typically handles a specific business capability and communicates with other services using APIs or messaging.

Q2. What is the main difference between monolithic and microservices architecture?

A monolith is generally developed and deployed as one application, whereas microservices divide functionality into independently deployable services.

Q3. Does every microservice need its own database?

Each microservice should ideally own its data. This doesn't necessarily require a separate physical database server for every service, but other services should access that data through the owning service's contract rather than directly modifying its tables.

Q4. How do microservices communicate?

Primarily through:

Synchronous:
REST / HTTP
gRPC

Asynchronous:
RabbitMQ
Kafka
Azure Service Bus

Q5. What is an API Gateway?

An API Gateway provides a common entry point for clients and routes requests to appropriate backend services. It may also handle concerns such as authentication, rate limiting, routing and request aggregation.

Q6. What happens if one microservice fails?

A well-designed system should prevent one service failure from causing cascading failures. Common techniques include:

• Timeouts
• Retries
• Circuit breakers
• Bulkheads
• Graceful degradation
• Asynchronous messaging

Q7. How do you handle transactions across microservices?

Traditional cross-service database transactions are generally avoided. Systems often use approaches such as the Saga Pattern, compensating actions, eventual consistency and transactional outbox.

Q8. How do you monitor a request across multiple microservices?

Use distributed tracing with a Trace ID/Correlation ID together with centralized logs and metrics. OpenTelemetry is commonly used for this purpose.

Q9. What are the major challenges of microservices?

Major challenges include:

• Network failures
• Distributed transactions
• Data consistency
• Service discovery
• Deployment complexity
• Observability
• Security
• Versioning
• Testing
• Debugging

Q10. Is Microservices Architecture suitable for every project?

No. Small applications may gain little benefit while inheriting substantial infrastructure and operational complexity. A monolith or modular monolith may be more appropriate.

Q11. What is the most important principle when identifying microservices?

Define services around business capabilities and domain boundaries, rather than simply creating separate services for controllers, repositories, tables, or technical layers.

Q12. Can two microservices share the same database?

Technically yes, but direct shared-table access creates tight coupling and weakens service independence. Prefer clearly defined data ownership and communication through APIs/events.

Interview one-line answer

Microservices Architecture structures a large application as a collection of loosely coupled, independently deployable services aligned to business capabilities, communicating through well-defined APIs or messaging and typically owning their own data.