What are Microservices?

Microservices is a way of building software where the whole application is divided into small, separate parts (called services).
Each part focuses on one specific job (like user login, payment, or notifications) and can work independently.

These services are:

• Self-contained: Each has its own code, database, and logic.
• Focused: Each does one business task well.
• Independent: They can be built, updated, and deployed separately without affecting the whole system.

💡 Example:

Think of an online shopping app:

• One service handles user accounts
• Another handles payments
• Another tracks orders
  Each of these runs on its own, but together, they form the full app.

Principles Used to Design Microservice Architecture

1. Independent & Autonomous Services
2. Scalability
3. Decentralization
4. Resilient Services
5. Real-Time Load Balancing
6. Availability
7. Continuous delivery through DevOps Integration
8. Seamless API Integration and Continuous Monitoring
9. Isolation from Failures
10. Auto -Provisioning

Design Patterns of Microservices

1. Aggregator
2. API Gateway
3. Chained or Chain of Responsibility
4. Asynchronous Messaging
5. Database or Shared Data
6. Event Sourcing
7. Branch
8. Command Query Responsibility Segregator
9. Circuit Breaker
10. Decomposition

CQRS (Command Query Responsibility Segregation)

CQRS stands for Command Query Responsibility Segregation.It’s a system design pattern where you separate the code that updates data from the code that reads data.

🧠 In Simple Words:

• Commands = change the data (Create, Update, Delete)
• Queries = read the data (Get info, View records)

Instead of having a single method or service that does both, you split them so they work independently.

📦 Why Use CQRS?

• You can optimize reads and writes separately
• It helps with scalability – e.g., fast queries even when many updates happen
• It makes code cleaner and easier to maintain

🍽 Example (Food App):

• Command: "PlaceOrder" updates the database with a new order
• Query: "GetOrderHistory" just reads and shows your past orders

They go through different paths, even if they use the same database.

🚗 What is the Sidecar Pattern?

The Sidecar pattern is a design pattern in microservices where you pair a helper service (sidecar) with your main application service.
They run together, usually in the same container or pod, and communicate locally.

Think of it like this:

Your microservice is the driver, and the sidecar is the helpful passenger handling extras like navigation, music, or snacks.

🔧 What does the Sidecar do?

The main microservice focuses on business logic.
The sidecar handles cross-cutting concerns, like:

• Logging
• Monitoring
• Proxying or routing
• Security (e.g., mTLS)
• Configuration updates

💡 Why Use Sidecar?

• Separation of concerns: Clean code in your main service
• Reusability: One sidecar can work with many services
• Language-agnostic: Works no matter what language your main service uses
• Great for Kubernetes: Often used with service mesh (like Istio or Linkerd)

📦 Real Example:

In Kubernetes, a pod might contain:

• Your application container
• A sidecar container (e.g., Envoy proxy for network handling)

⚡ What is the Circuit Breaker Pattern?

The Circuit Breaker Pattern is used to handle failures gracefully in distributed systems. It stops a failing service from being called repeatedly, which prevents overloading it and helps the whole system stay healthy.

🔌 Simple Analogy:

Think of an electric circuit in your home. If there's a power surge, the circuit breaker trips and cuts the connection to avoid damage.

In microservices:

• If a downstream service keeps failing (e.g., a payment gateway), the circuit breaker “trips” and temporarily stops requests to it.
• Once the service recovers, the circuit breaker resets and allows traffic again.

🔄 3 States of Circuit Breaker:

• Closed – Everything works fine; requests pass through.
• Open – Service is failing; no requests are allowed.
• Half-Open – Testing if service has recovered by allowing limited requests.

💡 Benefits:

• Improves system resilience
• Avoids cascading failures
• Helps in auto-recovery