When I started giving interviews, I was comfortable with:
✔ Spring Boot
✔ JPA
✔ REST APIs
I had prepared these topics well.
But in most interviews, one or two microservices questions were asked.
And honestly, I was not prepared.
Sometimes I fumbled.
Sometimes I hesitated.
Sometimes I knew the concept but could not answer properly or maybe mixed with another concept.
And sometimes I just said: “I don’t know”
Later I realized something.
Even if we don’t know the complete answer, giving even a one-line answer creates a better impression than staying blank.
So, I started creating topic-wise notes.
Goal was simple:
- Understand quickly
- Remember quickly
- Answer confidently
These are the notes I prepared.
1. Monolith → Microservices
How to convert Monolith to Microservices?
(i) Understand & Break the Domain
Use Domain Driven Design (DDD)
Identify service boundaries / bounded contexts.
Examples:
- User
- Order
- Payment
(ii) Extract Services Gradually
Don’t rewrite everything.
Use: Strangler Fig Pattern
Extract one service at a time.
(iii) Database Separation
Each service should have its own database.
Avoid shared DB.
(iv) Implement Communication
- Sync
- Async
(v) Add API Gateway
Single entry point.
(vi) Service Discovery
Services dynamically locate each other.
(vii) Handle Cross Cutting Concerns
- Config
- Security
- Logging
- Monitoring
(viii) Deploy Independently
Docker + CI/CD.
Interview Scenario Questions
Q1. Small change in one module requires redeploying the whole application. What architecture issue do you see?
Q2. Order module scaling impacts User module. How would you solve this?
2. Asynchronous vs Synchronous Communication
Synchronous (Sync)
Client waits for response (that is why blocking).
Examples:
- Payment processing
- Login validation
Characteristics:
- Tight coupling
- Immediate response
- Slower
- Failure propagates
Asynchronous (Async)
Client does not wait (that is why non-blocking).
Examples:
- Email notification
- Order processing
- Logging
Characteristics:
- Loose coupling
- Better scalability
- Fault tolerant
Examples:
- Kafka
- RabbitMQ
Memory Hook:
Sync waits. Async moves.
Interview Scenario Questions
Q1. Order API is slow because email notification runs in same flow. What would you change?
Q2. User must immediately see payment confirmation. Sync or Async?
3. RestTemplate vs Spring WebClient vs Feign Client
RestTemplate
- Blocking (since it is sync.)
- Synchronous
Spring WebClient
- Reactive
- Async
- Non-blocking
Replacement of RestTemplate.
Feign Client
Declarative HTTP client.
Used for service-to-service communication.
Interview Scenario Questions
Q1. Thousands of external API calls are blocking threads. Better option?
Q2. Service-to-service API code is repeatedly written. Better approach?
4. Kafka vs RabbitMQ
Kafka
- High throughput (Millions msg per sec.)
- Message retention
- Event streaming
Pull based.
Consumer pulls message at own pace, producer just produde the message and move on with its task.
Use cases:
- Logging
- Notifications
- Order processing
RabbitMQ
Traditional broker.
Push based.
Broker pushes messages to consumers.
Reliable delivery.
Memory Hook
Kafka pulls. Rabbit pushes.
Interview Scenario Questions
Q1. Millions of logs generated per second. Kafka or RabbitMQ?
Q2. Reliable order processing with message delivery required. Which tool fits?
5. API Gateway in Microservices
Definition:
Entry point for all requests.
Responsibilities:
- Routing
- Load balancing
- Security
- Logging
- Rate limiting
Examples:
- Spring Cloud Gateway
- NGINX
Why API Gateway Needed?
Without API Gateway client must know:
(i) Service URLs
(ii) Different Ports
(iii) Authentication Mechanism
(iv) How to combine response
(v) Internal architecture
This creates:
Tight coupling between client and server.
API Gateway Solution
✔ One public endpoint
✔ Hide internal architecture
✔ Handle cross-cutting concerns
Implementation
(i) Add dependency
(ii) Configure routes in application.yml file
(iii) Add cross cutting concerns like logging, rate limiting, security, etc.
Interview Scenario Questions
Q1. Client knows all service URLs and ports. What problem exists?
Q2. Authentication and logging implemented in every service. Better solution?
6. Rate Limiting
Definition:
Restrict no of requests a client can make in a given time to prevent abuse and improve stability.
Benefits:
- Fair usage
- Better performance
Algorithms:
- Fixed Window
- Sliding Window
- Token Bucket
- Leaky Bucket
Best place to implement:
API Gateway (best) or Load Balancer
Tools:
- Resilience4j (rate limiter module)
- Bucket4j
- Redis
Interview Scenario Questions
Q1. One user sends 10k requests and backend crashes. What should be introduced?
Q2. API abuse prevention approach?
7. Service Discovery Pattern
Definition:
Dynamically locate services using registry like Eureka.
Why is it needed?
(i) Services often scaled up and down
(ii) Deployed on different servers
(iii) Running dynamic ports
Because of the above reasons location/IP of the services keep changing so Service Discovery helps in avoiding “hardcoded service URLs”. It scales the application dynamically and promotes fault tolerance.
Types
Client Side
Client fetches services instance from registry. e.g. Eureka + Ribbon
Server Side
Load Balancer fetches services instances. e.g. API Gateway / Load Balancer
Components
- Service Registry: Stores services instances
- Service Provider: Register itself
- Service Consumer: Discover and calls services
How it works:
(i) Service registers with registry (Eureka)
(ii) Client Queries Registry and gets available instances
(iii) Makes request to service
Interview Scenario Questions
Q1. Service IP changed after scaling and calls started failing. Why?
Q2. Why avoid hardcoded service URLs?
8. Load Balancer
Definition:
Distributes requests across service instances.
Goal:
- Scalability
- High availability
- Fault tolerance
Algorithms:
- Round Robin
- Least Connections
- Weighted
Interview Scenario Questions
Q1. One instance overloaded while others idle. Solution?
Q2. Sale traffic increased suddenly. How will requests be distributed?
9. Circuit Breaker
Definition:
Stops calls to failing service after a threshold and resumes only after recovery.
Benefits:
- Avoid cascading failures
- Improve fault tolerance
States of Circuit Breaker
Closed → Normal (requests are allowed, no failure in services)
Open → Calls blocked (failure is there and threshold reached)
Half Open → Test recovery (few requests 50% are allowed to see if failure stopped or not)
How it works
(i) Service fails repeatedly
(ii) Circuit Breaker opens and further calls to service is blocked (for a limited time as per configuration).
(iii) After timeout circuit is half opened to check if service starts responding.
(iv) If success circuit is closed and request is allowed else open again.
Interview Scenario Questions
Q1. Service chain A → B → C. C keeps failing continuously. How prevent failure propagation?
Q2. Continuous retries degrading system performance. What pattern helps?
10. Saga Design Pattern
Definition:
Distributed transaction using local transactions with compensating action.
Avoid:
2PC (2 Phase Commit) (It is an all-or-nothing rule. Either everyone updates together, or nobody does.)
Why needed?
In monolith application if something unexpected happen it is rollbacked (whatever updated in db just delete that). But in microservices architecture each service (order, payment, inventory) has its own database rolling back all services is not possible easily.
Instead of rollback, we perform compensating action.
Example:
Step 1 → Create Order
Step 2 → Reserve Inventory
Step 3 → Process Payment
If step 3 fails, SAGA performs compensating action: –
- Cancel inventory
- Cancel order
So, the system returns to a consistent state.
Types
Choreography
Services communicate through events e.g. Kafka
Orchestration
A central orchestrator controls workflow.
Example: Camunda or BPMN
Interview Scenario Questions
Q1. Payment succeeded but inventory failed. How maintain consistency?
Q2. Global rollback difficult because each service owns DB. Solution?
11. Configuration Management
Definition:
Manage external configs:
- DB URL
- API keys
- Environment configs
Need:
- Avoid hardcoding
- Dev/Test/Prod support
- Dynamic updates
Tool: Spring Cloud Config
Note: Store config file outside the application either locally or on external server and load at run time throgh environment variables.
Interview Scenario Questions
Q1. DB URL changed and all services needed redeployment. Better approach?
Q2. How manage Dev / Test / Prod configs centrally?
Final Learning
You just need enough knowledge so that you don’t stay silent in interviews.
Even one meaningful line creates confidence.
Note: Microservices is a very vast topic and not limited to only these concepts. Even these topics can be explored much deeper, but these are some of the commonly asked interview topics and a good starting point for preparation.
Happy Learning!!
Microservices Interview Preparation— The Notes That Helped Me Stop Saying “I Don’t Know” was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.
This post first appeared on Read More