Microservice Interview Questions: The basics

Microservices have become an increasingly popular architectural style for building complex, scalable applications. Chances are, if you're working on a modern system, you'll be working on a microservice architecture.

At Metoro, not only do we run a microservice architecture ourselves, our product itself analyses and automatically debugs the microservices of our customers. This means that all our engineers need to have a solid understanding of microservices.

In this post, we'll teach you about microservices through question-answer pairs starting off with the basics and getting into the details with a lot of help from diagrams.

1. What are microservices?

Microservices are an architectural approach to building applications as a collection of small, independent services. Each service is focused on a specific business capability and can be developed, deployed, and scaled independently.

Microservices communicate with each other through well-defined APIs, typically using protocols such as HTTP/REST or messaging queues.

The alternative to using microservices would be to use a monolith. A monolith is a much larger single program which would perform the actions of multiple different microservices.

In the diagram above, we have a monolith and a microservice architecture. They both accomplish the same task but in the microservice architecture we have smaller individual components vs a large single component in the monolithic application.

Now you're probably thinking the microservice architecture seems much more complicated? You'd be correct, in general orchestrating microservices is more complicated than just having a monolith. But there are benefits which we'll talk about now.

2. What are the benefits of using microservices?

There are a bunch of benefits to adopting a microservices architecture.

Scalability

Microservices can be scaled independently based on the specific needs of each service, allowing for better resource utilization and performance.

In this example above, let's say that functionality A is encompassed by service A in our microservice architecture. Now lets say that our workload requires a lot of this A functionality to handle demand. In a microservice architecture, we can just add more of the service responsible for A. In a monolith, we have to add more of the entire monolith which likely comes with a bunch more overhead for each instance.

Flexibility

If your monolith is in Java and you want to add new functionality which would be better suited to something more low-level like rust / C, well tough.

You could do something like calling rust via FFI but that's probably a whole bunch of complexity you don't want.

In a microservice-based arch, you can pick the right tool for the right job. This is because all communication is performed via some intermediate protocol (like HTTP) across the network. So as long as your desired language has an HTTP server and an HTTP client then you're good to go.

Resilience

If one microservice fails, it doesn't necessarily bring down the entire application. Proper isolation and fault tolerance mechanisms can help maintain overall system availability.

In the architecture above, a crash in any of the functionality in each of the components in the monolith, leads to a crash of the entire service so no requests can be processed. In the microservice architecture, we just lose that functionality. So let's say that we're a company that builds an e-commerce platform. If our recommendation service crashes, we could still do everything else like processing payments and checkouts. In our monolith, our entire app would be down.

Mirroring the organizational structure

This is the real benefit of microservices. Microservices split the functionality of the app to a level that an individual team is responsible for an entire microservice. This makes coordination much easier. There's a single point of contact and owner for each piece of functionality. This allows engineering organizations to scale much more efficiently.

In this architecture, we might have the following teams:

• Payments team

• Shipping team

• Auth team

• Order management team

• Product Catalog team

• Frontend team

3. What are the challenges of using microservices?

While microservices offer many benefits, they also introduce some challenges:

Complexity

Managing a distributed system with multiple services can be complex, requiring careful coordination and communication between teams.

Lets say that a team needs to change the API of one of their services. Because the API is consumed by a bunch of other services, they'd have to run an api migration. This is much more complicated than just changing a function signature and updating all references to it internally. More on this later.

Data consistency

Ensuring data consistency across multiple services can be challenging, especially when dealing with distributed transactions.

When you're running a microservice architecture, it's desirable to split your database tables for each service so that each team can quickly iterate on their data model. Some companies take this a step further and they use different databases entirely. This makes ACID properties hard to maintain as you dont have access to consistent transactions across different databases.

In this diagram, you can see the added overhead of maintaining additional db entries for a single transaction.

Network latency

As microservices communicate over the network, latency can become a concern, impacting overall system performance. This is generally not a concern for most applications but if you're doing something like high-frequency trading, you probably wouldn't want to use microservices due to the extra few milliseconds.

Debugging and monitoring

Identifying and troubleshooting issues in a microservices environment can be more difficult due to the distributed nature of the system.

You can use distributed tracing to help tame the complexity, more on this in our other blog post.

Operational overhead

Deploying and managing numerous services requires robust infrastructure and automation to ensure smooth operations. Something like kubernetes can help here, but again this adds more complexity.

4. How do microservices communicate with each other?

Microservices typically communicate with each other using lightweight protocols and APIs. Some common communication patterns include:

• HTTP: Microservices host http endpoints and call each other with http clients.

• Message Queues: Services can communicate asynchronously using message queues or pub/sub systems like Apache Kafka or RabbitMQ.

• gRPC: gRPC is a high-performance, open-source framework that uses Protocol Buffers for efficient binary serialization and supports various languages.

• GraphQL: GraphQL provides a flexible query language for APIs, allowing clients to request specific data they need from multiple services.

5. What is service discovery?

Service discovery is the process of automatically detecting and locating services within a microservices ecosystem. In a dynamic environment where services can be added, removed, or moved across different hosts, service discovery becomes crucial. It allows services to find and communicate with each other without hardcoding network locations.

There are a few different ways to do service discovery but the main one is via a service registry.

When doing service discovery via a service registry each service registers itself with the registry so that clients can query for their location when they need to make requests. The service registry has a well-known static location so that it can be found without a query.

6. What is the role of API gateways in microservices?

API gateways act as the entry point for client requests in a microservices architecture. They provide a unified interface to the outside world, abstracting the internal microservices landscape. API gateways handle tasks such as:

• Request routing: Routing client requests to the appropriate microservices based on the request path, headers, or other criteria.

• Protocol translation: Converting between different protocols used by clients and microservices, such as HTTP to gRPC or WebSocket.

• Authentication and authorization: Enforcing security policies and validating client credentials before forwarding requests to microservices.

• Rate limiting and throttling: Controlling the rate of incoming requests to prevent overloading the system.

7. How do you handle versioning in microservices?

Versioning is important in microservices to allow for the independent evolution of services and to maintain compatibility with existing clients.

A common way of doing this is via URL versioning: This is where you include the version number in the API URL, such as /api/v1/users or /api/v2/products.

When we're running a migration from v1 to v2 it looks something like this.

We need a transition period to allow clients to move over. This can be a pretty big burden if you're changing your api frequently.

8. How do you handle fault tolerance and resilience in microservices?

There's a tonne to know here and we won't cover things in detail. We'll have some more posts coming out on this soon so be sure to subscribe to get them straight to your inbox.

• Circuit breakers: Prevents cascading failures. If a service is unresponsive or failing, the circuit breaker can trip and prevent further requests from being sent to that service.

• Retry mechanisms: Allows you to handle transient failures. If a request fails, it can be retried after a certain delay, allowing the system to recover from temporary issues.

• Fallbacks: Allows you to handle service failures gracefully. This can include returning default or cached responses, using alternative services, or degrading functionality in a controlled manner.

• Bulkheads: Divides the system into separate pools or partitions to prevent a failure in one part from affecting the entire system.

• Redundancy and replication: Deploy multiple instances of microservices and use load balancing to distribute traffic. This ensures that if one instance fails, others can continue serving requests.

Conclusion

There's a bunch to know about microservices and a lot to research. I hope this post gives you a good jumping-off point to do some more searching yourself!