The Top 10 Microservice Interview Questions Most Likely to Appear in an Interviews
These are top 10 Microservice interview questions mostly likely to appear in an interview.
Are you preparing for a job interview as a Java developer?
Find my book Guide To Clear Java Developer Interview here Gumroad(PDF Format) and Amazon (Kindle eBook).
Guide To Clear Spring-Boot Microservice Interview here Gumroad (PDF Format) and Amazon (Kindle eBook).
Download the sample copy here: Guide To Clear Java Developer Interview[Free Sample Copy]
Guide To Clear Spring-Boot Microservice Interview[Free Sample Copy]
If you are looking for Personalise guidance here is the 1:1 link — https://topmate.io/ajay_rathod11
1. What is the SAGA and CQRS Microservice design patterns?
In enterprise applications, nearly every request is executed within a database transaction.
Developers often use frameworks and libraries with declarative mechanisms to simplify transaction management.
The Spring framework, for example, uses a special annotation to arrange for method invocations to be automatically executed within a transaction. This annotation simplifies writing transactional business logic, making it easier to manage transactions in a monolithic application that accesses a single database.
However, while transaction management is relatively straightforward in a monolithic application accessing a single database, it becomes more complex in scenarios involving multiple databases and message brokers.
For example, in a microservice architecture, business transactions span multiple services, each with its database. This complexity makes the traditional transaction approach impractical. Instead, microservices-based applications must adopt alternative mechanisms to manage transactions effectively.
In this post, we’ll learn why microservices-based applications require a more sophisticated approach to transaction management, such as using the Saga pattern. We’ll also understand the different approaches to implementing the Saga pattern in an application.
2. What is the CQRS Microservice Design Patterns?
CQRS, which stands for Command Query Responsibility Segregation, is an architectural pattern that separates the concerns of reading and writing data.
It divides an application into two distinct parts:
- The Command Side: Responsible for managing create, update, and delete requests.
- The Query Side: Responsible for handling read requests.
The CQRS pattern was first introduced by Greg Young, a software developer and architect, in 2010. He described it as a way to separate the responsibility of handling commands (write operations) from handling queries (read operations) in a system.
The origins of CQRS can be traced back to the Command-Query Separation (CQS) principle, introduced by Bertrand Meyer. CQS states that every method should either be a command that performs an action or a query that returns data, but not both. CQRS takes the CQS principle further by applying it at an architectural level, separating the command and query responsibilities into different models, services, or even databases.
Since its introduction, CQRS has gained popularity in the software development community, particularly in the context of domain-driven design (DDD) and event-driven architectures.
It has been successfully applied in various domains, such as e-commerce, financial systems, and collaborative applications, where performance, scalability, and complexity are critical concerns.
In this post, we’ll learn about CQRS in comprehensive detail. We will cover the various aspects of the pattern along with a decision matrix on when to use it.
follow-up Question —
3.How to maintain a session between two microservices?
- Use a shared database, cache, or session store to maintain session data.
- Popular technologies: Redis, Memcached, or a relational database.
- Microservices access this store to retrieve session-related information.
As per 12 Factor App guide lines all the services should be stateless.
Your API should be stateless therefore do not share the session state to the microservices. The recommended approach is to set up a Redis cache to store session data.
Additional Reading:
https://www.baeldung.com/cqrs-event-sourcing-java
https://microservices.io/patterns/data/saga.html
Write an endpoint in spring boot for getting and saving employees with syntax.
4. How to communicate between two microservices?
The communication styles in microservices can be categorized into synchronous and asynchronous, each with distinct characteristics and implementations:
- Synchronous Communication:
- Relies on protocols like HTTP, commonly used in web applications and microservices.
- The client sends a request and waits for a response from the service.
- While HTTP is synchronous and stateless, asynchronous interaction with the server is possible using libraries like Spring Cloud Netflix.
- Frameworks like Vert.x or Node.js support asynchronous callbacks within a synchronous protocol.
2. Asynchronous Communication:
- Focuses on ensuring the client does not block threads while waiting for a response.
- Typically uses messaging brokers (e.g., RabbitMQ, Apache Kafka) and the AMQP protocol.
- The producer sends a message to the broker and awaits acknowledgment, not the actual response.
- Supports one-to-one (queue) or one-to-many (topic) communication modes.
- Frameworks like Spring Cloud Stream facilitate building message-driven microservices.
Both styles have their place in microservice architectures, depending on the use case and system requirements
What to use:
- Option 1 (the best): Use a queue system to share messages, so if Microsoervice B needs some information from Microservice A, A will send a message to the queue and B will consume it. This is the most resilient solution as, if B is down, it will consume the message anyway when it recovers.
- Option 2: Use a RESTFul endpoint, you can call from A to inform B or from B to get information from A. The problem is that, if the receiver is down or failing, the request will break and you will desync. You need to implement a circuit-breaker then to avoid losing it.
4. Where to save your username password in the spring boot-based microservices application?
Use Password Hashing
Don’t store passwords in plain text. Spring Security doesn’t allow plain text passwords by default. PasswordEncoder is the main interface for password hashing in Spring Security:
5. How does Oauth/JWT works internally, and how to make sure your token has not been tampered with?
JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed — for example, using public/private key pairs — you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn’t been tampered with.
7. How to handle exceptions in Spring boot application what are the best practices to do it?
To handle exceptions in Spring Boot microservices, you can use several approaches
Global Exception Handling:
@ControllerAdvice: Create a class annotated with @ControllerAdvice to handle exceptions globally.
@ExceptionHandler: Use the @ExceptionHandler annotation to handle specific exceptions or their parent classes.
Methods and Responses: Implement methods in the class that return appropriate HTTP response codes and error messages based on the handled exception.
8. Design rest API for tiny URL application, how many endpoints it requires, and based on that there is a discussion on it. so, it’s a system design question.
Here is my article on it.
9. How to restrict the microservices from calling the other microservices?
Use a reverse proxy. We use Nginx for the same purpose. Api gateways should always be deployed behind a load balancer in production scenarios to avoid the gateway being a single point of failure(If it is not a managed service like AWS API gateway). Also, the gateway and services are deployed within a VPC and not visible to the public.
10. let’s say there are A, B, C, D, and E-services and I want to restrict A to call to C, D, and E. how will you do that?
There are several ways to restrict service A from calling services other than C, D, and E, depending on the environment and technologies you’re using. Here are a few common approaches:
1. API Gateways/Service Mesh:
- How it works: An API gateway or service mesh acts as a central point of entry for all service requests. It can enforce policies, including access control.
- Implementation: You would configure the gateway/mesh to only allow requests from service A to services C, D, and E. Any requests from A to other services would be blocked.
- Advantages: Centralized control, easy to manage and update policies, often provides other features like rate limiting and monitoring.
- Examples: Kong, Apigee, Istio, Linkerd.
2. Network Policies (e.g., Kubernetes Network Policies):
- How it works: Network policies operate at the network layer (Layer 3/4) and control traffic flow between pods (in Kubernetes) or other network entities.
- Implementation: You would define a network policy that allows ingress traffic to pods of services C, D, and E only from the pod(s) of service A.
- Advantages: Fine-grained control at the network level, efficient, often integrated with the container orchestration platform.
- Examples: Kubernetes Network Policies, Calico.
3. Service Discovery and Registration with Access Control:
- How it works: Services register themselves with a service registry (e.g., Consul, etcd, ZooKeeper). When service A wants to call another service, it queries the registry.
- Implementation: You can extend the service registry or use a separate authorization service to manage access control lists (ACLs). When A queries for service B, the registry checks the ACL and only returns the endpoint if A is allowed to call B.
- Advantages: Decouples services, allows for dynamic service discovery.
- Examples: Consul with ACLs, custom authorization service.
4. Code-Level Authorization:
- How it works: Implement authorization logic directly within service A.
- Implementation: Before making a call to another service, service A checks a configuration file or queries an authorization service to determine if the call is allowed.
- Advantages: Simple to implement for basic cases.
- Disadvantages: Decentralized control, harder to manage and update policies, adds complexity to each service.
The above list of questions has been asked recently in a fintech company interview. please go through it as they are good pointers to search the topic and add depth to your knowledge.
Other Useful Articles for Java developers
How I got more than 10 offer letters as a Java Developer in 3 months.
How I Learned Java in Depth by preparing for Java Technical Interviews
Microservice Interview questions for Backend Developers series-2 (CIRCUIT-BREAKER)
Microservice Interview questions for Backend Developers series-1
17 Java Developer Interview Question Series-9(Experienced candidates 0–6 years)
13 New Java Developer Interview Question Series-6 (Microservices and Java Coding)
250+ Java/SpringBoot/Microservice Interview Questions Book(My New Book Announcement for Java Developer)
Thanks for reading
- 👏 Please clap for the story and follow me 👉
- 📰 Read more content on my Medium (21 stories on Java Developer interview)
Find my books here:
