Just got this Book published on Amazon Kindle check it out at https://www.amazon.ca/dp/B07KMD77YB/ref=sr_1_4?ie=UTF8&qid=1542400692&sr=8-4&keywords=microservices+interview+questions

Wisdom is learning all we can but having the humility to realize that we do not know it all. Microservices Interview Questions 90 Technical questions with clear and concise answers will help you gaining more wisdom in Microservices Interviews. The difference between a great Microservices consultant and someone who kind of knows some stuff is how you answer the interview questions in a way that will show how knowledgeable you are. The 90 questions I have assembled are for: job seekers (junior/senior developers, architects, team/technical leads), and interviewers.

Microservices Interview Questions are grouped into:

• General Questions
  
• Design Patterns Questions
  
• API Design Questions
  
• Containers and Orchestrations Questions.
  

Increase your earning potential by learning, applying and succeeding. Learn the fundamentals relating to Microservices based Application architecture in an easy to understand questions and answers approach. It covers 90 realistic interview Questions with answers that will impress your interviewer. A quick reference guide, a refresher and a roadmap covering a wide range of microservices architecture related topics & interview tips.

Sample Questions

1. Why a Microservices architecture?

Microservices Architecture provides long-term agility. Microservices enable better maintainability in complex, large, and highly-scalable systems by letting you create applications based on many independently deployable services that each have granular and autonomous lifecycles. And Microservices can scale out independently.

Instead of having a single monolithic application that you must scale out as a unit, you can instead scale out specific Microservices. That way, you can scale just the functional area that needs more processing power or network bandwidth to support demand, rather than scaling out other areas of the application that do not need to be scaled. That means cost savings. Microservices approach allows agile changes and rapid iteration of each Microservice. Architecting fine-grained Microservices-based applications enables continuous integration and continuous delivery practices. It also accelerates delivery of new functions into the application. Fine-grained composition of applications also allows you to run and test Microservices in isolation, and to evolve them autonomously while maintaining clear contracts between them. As long as you do not change the interfaces or contracts of a Microservice, you can change the internal implementation of any Microservice or add new functionality without breaking other Microservices that use it.

1. What is the Eventual Consistency?

Eventual consistency is an approach which allow you to implement data consistency within a Microservices architecture. It focuses on the idea of that the data within your system will be eventually consistent and it doesn’t have to be immediately consistent. For example, in an E-Commerce system, when a customer places an order, do you really need to immediately carry out all the transactions (Stock availability, charging the customer credit card, etc.)? There are certain data updates that can be eventually consistent, in line with the initial transaction that was triggered. This approach is based on the BASE model (Basic Availability, Soft state, and Eventually consistent). Data updates can be more relaxed, and don’t always have to have all the updates apply to the data immediately, slightly stale data to give approximate answers is okay sometimes. BASE model contrasts with the ACID model where all data related to the transaction must be immediately updated as part of the transaction. The system becomes more responsive because certain updates are done in the background and not done as part of the immediate transaction. The eventual consistency approach is highly useful for long running tasks. One thing to note about the eventual consistency approach is depending on the patterns you use, the actual time it takes for the data to become consistent will not be days, minutes or hours, it will potentially be seconds. Eventual data consistency across your Microservices architecture that happens within seconds is acceptable because of the gains you get in terms of performance and responsiveness across your system. Eventual consistency using the right patterns can be so immediate, and preparing for inconsistencies and dealing with race conditions might not actually be such a huge task. The traditional approach to eventual consistency has involved using data replication. Another approach to eventual consistency is Event based which works by raising events as part of transactions and actions in an asynchronous fashion as messages are placed on message brokers and queues.

1. How to approach REST API Design?

   1. First, focus on the business entities that the web API exposes, what kind of CRUD operations needed. Creating a new entity record can be achieved by sending an HTTP POST request that contains the entity information. The HTTP response indicates whether the record was created successfully or not. When possible, resource URIs should be based on nouns and not verbs like the operations on the resource. A resource does not have to be based on a single physical data item.
      
   2. Avoid creating APIs that simply mirror the internal structure of a database. The purpose of REST is to model entities and the operations that an application can perform on those entities. A client should not be exposed to the internal implementation.
      
   3. Entities are often grouped together into collections (orders, customers). A collection is a separate resource from the item within the collection, and should have its own URI.
      
   4. Sending an HTTP GET request to the collection URI retrieves a list of items in the collection. Each item in the collection also has its own unique URI. An HTTP GET request to the item’s URI returns the details of that item.
      
   5. Adopt a consistent naming convention in URIs. In general, it helps to use plural nouns for URIs that reference collections. It’s a good practice to organize URIs for collections and items into a hierarchy.
      
   6. You should provide navigable links to associated resources in the body of the HTTP response message. Avoid requiring resource URIs more complex than collection/item/collection.
      
   7. Try to keep URIs relatively simple. Once an application has a reference to a resource, it should be possible to use this reference to find items related to that resource.
      
   8. Try to avoid “chatty” web APIs that expose many small resources. Such an API may require a client application to send multiple requests to find all of the data that it requires. Instead, you might want to denormalize the data and combine related information into bigger resources that can be retrieved with a single request. However, you need to balance this approach against the overhead of fetching data that the client doesn’t need. Retrieving large objects can increase the latency of a request and incur additional bandwidth costs.
      
   9. Avoid introducing dependencies between the web API and the underlying data sources. For example, if your data is stored in a relational database, the web API doesn’t need to expose each table as a collection of resources.
      

It might not be possible to map every operation implemented by a web API to a specific resource. You can handle such non-resource scenarios through HTTP requests that invoke a function and return the results as an HTTP response message. For example, a web API that starts some operation such as run validations could provide URIs that expose these operations as pseudo resources and use the query string to specify the parameters required.