1) what is micro services architecture and how does it work?
A)Microservices architecture is a way of designing software systems where an application is built as a collection of small, independent services that communicate with each other over a network.
Instead of having one big, tightly integrated monolithic codebase, you break it into smaller, self-contained components—each responsible for a specific business function.
How It Works
1. Decomposition into Services
Each micro service handles a single, well-defined capability (e.g., User Management, Payment Processing, Inventory Tracking).
Services are developed, deployed, and scaled independently.
2. Independent Deployment
You can update or replace one service without redeploying the whole system.
This enables faster releases and easier experimentation.
3. Communication Between Services
Services talk to each other using APIs (often HTTP/REST, gRPC, or messaging systems like Kafka or RabbitMQ).
Data sharing is typically minimal—each service usually has its own database to maintain independence.
4. Service Discovery & Load Balancing
A service registry helps services find each other dynamically.
Load balancers distribute requests across multiple instances.
5. Resilience & Scaling
If one service fails, others can still operate (assuming proper design).
You can scale only the services that need extra capacity instead of the whole system.
6. Technology Flexibility
Teams can choose different programming languages, frameworks, and storage solutions for each micro service (as long as they speak the agreed-upon communication protocols).
Example
Imagine an e-commerce platform:
Auth Service – Handles login and registration
Catalog Service – Manages product listings
Cart Service – Handles shopping cart operations
Payment Service – Processes transactions
Shipping Service – Calculates delivery estimates and handles logistics
If you need to improve payment speed, you just update the Payment Service without touching the rest.
Advantages
Scalability – Scale services independently
Faster Development – Parallel work by small teams
Resilience – Failure in one service won’t necessarily crash the whole app
Tech Diversity – Use the right tool for each job
Challenges
Complexity – More moving parts than monolithic architecture
Data Consistency – No single database, so distributed transactions are harder
Networking Overhead – More API calls = higher latency potential
DevOps Skills Needed – CI/CD pipelines, containerization (Docker, Kubernetes) often required
1. Steps to Implement Microservices Architecture
Step 1 – Identify Business Capabilities Break down your application into domains (e.g., Billing, Orders, Shipping, Inventory).
Each domain becomes a microservice.
Step 2 – Define Service Boundaries
Clearly define what each service is responsible for.
Use Domain-Driven Design (DDD) concepts like bounded contexts.
Step 3 – Choose Communication Mechanism
Synchronous: REST, gRPC (for request-response)
Asynchronous: Message queues like RabbitMQ, Kafka (for event-driven)
Step 4 – Assign Independent Databases
Each service should have its own database to avoid tight coupling.
Choose storage type based on needs (SQL, NoSQL, in-memory).
Step 5 – Containerize Services
Use Docker to package services.
Orchestrate them with Kubernetes or ECS.
Step 6 – Implement Service Discovery
Use Eureka, Consul, or Kubernetes DNS to let services find each other dynamically.
Step 7 – Ensure Observability
Logging (ELK stack, Splunk)
Metrics (Prometheus, Grafana)
Tracing (Jaeger, Zipkin)
Step 8 – Secure the Services
API Gateway for routing & authentication.
OAuth 2.0 / JWT for securing endpoints.
2. Approaches to Building Microservices
A. Top-Down (Greenfield Development)
Build a brand-new system using microservices from scratch.
Best when starting a new project with no legacy constraints.
B. Bottom-Up (Refactoring Monolith)
Start from your existing monolith and gradually extract services.
Typical pattern:
1. Identify a feature.
2. Extract it as a microservice.
3. Connect via API Gateway.
Example: Extract Order Processing from your monolith into a separate service.
C. Strangler Fig Pattern
Replace monolith modules one by one with microservices until nothing of the monolith remains.
Both old and new code run together during migration.
D. Hybrid Approach
Keep core features in the monolith, and build new features as microservices.
Gradually replace monolith parts.
