🧩 Microservices & Architecture

1. Have you worked on microservice patterns?

Yes. I’ve worked with several common microservice patterns depending on system needs:

🔹 Key Patterns I’ve Used

• API Gateway Pattern A single entry point for clients that handles routing, authentication, rate limiting. 👉 Helps avoid exposing internal services directly.

• Database per Service Each microservice owns its database. 👉 Prevents tight coupling and enables independent scaling.

• Circuit Breaker Pattern Prevents cascading failures when a service is down. 👉 Example: fallback response when dependency fails.

• Service Discovery Services dynamically find each other (e.g., via Eureka/Consul).

• Saga Pattern (Distributed Transactions) Used when multiple services need to maintain data consistency. 👉 Either choreography (events) or orchestration (central controller).

---

2. How do you convert a monolithic application into microservices?

You don’t “break it overnight” like smashing a coconut. It’s more like carefully untying a knot 🪢.

🔹 Steps I Follow

1. Understand Domain (Domain-Driven Design)

   • Identify bounded contexts
   • Example: User, Payment, Order

2. Identify Service Boundaries

   • Split based on business capability, not technical layers

3. Decouple Database

   • Move towards database per service

4. Extract Services Gradually

   • Start with low-risk modules

5. Introduce API Layer

   • Use REST/GraphQL between services

6. Handle Cross-Cutting Concerns

   • Logging, monitoring, security

7. Deploy Independently

   • Use containers (Docker/Kubernetes)

---

3. What approach do you follow during migration?

🔹 Strangler Fig Pattern 🌿

This is the safest and most practical approach.

• Gradually replace parts of monolith with microservices
• Route specific functionality to new services
• Slowly “strangle” the monolith until it’s gone

🔹 My Migration Strategy

• Start with read-heavy or independent modules
• Introduce API Gateway
• Use feature toggles
• Maintain backward compatibility
• Monitor performance at every step

---

4. When do you use synchronous communication?

Synchronous = “I ask, I wait, I proceed.”

🔹 Use Cases

• Real-time response required 👉 Example: Login, Payment processing

• When immediate consistency is required

• Simple request-response workflows

🔹 Technologies

• REST APIs
• gRPC

⚠️ Trade-offs

• Tight coupling
• Higher latency
• Risk of cascading failures

---

5. When do you use asynchronous communication?

Asynchronous = “I drop a message and move on.” 📬

🔹 Use Cases

• Background processing 👉 Example: Email sending, notifications

• Event-driven workflows

• High scalability systems

• Loose coupling between services

🔹 Technologies

• Kafka
• RabbitMQ
• AWS SQS

✅ Benefits

• Better fault tolerance
• Improved scalability
• Services remain independent

---

6. Have you used event-driven architecture?

Yes. I’ve used event-driven architecture for building scalable and loosely coupled systems.

👉 Example:

• When an Order is placed

  • Order Service emits event
  • Payment Service listens
  • Notification Service sends email
  • Inventory updates stock

No direct service-to-service calls needed.

---

7. What is event-driven architecture?

Event-driven architecture is like a newsroom 🗞️ where events are headlines and services are journalists reacting to them.

🔹 Definition

A system where services communicate by producing and consuming events instead of direct calls.

🔹 Key Components

• Event Producer → generates event
• Event Broker → Kafka, RabbitMQ
• Event Consumer → reacts to event

🔹 Flow Example

1. User places order
2. Order Service publishes OrderCreated event
3. Multiple services react independently

🔹 Advantages

• Loose coupling
• High scalability
• Easy to extend system

🔹 Challenges

• Debugging is harder
• Event consistency issues
• Requires good monitoring

---