Microservices Interview Questions- Part 2

Answer:

1. Here are the main features of Microservices:
   • Microservices have several individually deployable components.
   • Service distribution in Microservices is based on the business capabilities.
   • It has decentralized data management.
   • Supports DevOps implementation.
   • It has technical independence.
   • Microservices have hidden component complexity to avoid unwanted Microservices dependencies.
2. • Decoupling- Services within a system are mostly decoupled. So, applications can be easily scaled, built, & altered.
   • Componentization- Microservices are treated as independent components that can be upgraded & replaced easily.
   • Business Capabilities- Microservices are simple & focuses on a single capability.
   • Autonomy- Developers can independently work with each other, thus increases speed.
   • Continuous Delivery- Enables frequent releases of software through systematic automation of testing, approval, & software creation.
   • Responsibility- Microservices don’t focus on apps as projects. Instead, they treat apps as products for which they are responsible.
   • Decentralized Governance- There is no standardized pattern or technology pattern. Developers have the flexibility to choose the best tools to solve their problems.
   • Agility– Microservices support agile development & quicker development.

Answer:

1. Below are the key components of Microservices:
   • Clustering, Containers, & Orchestration
   • Infrastructure as Code Conception (IaC)
   • Enterprise Service Bus
   • Service Delivery
   • Cloud Infrastructure
   • API Gateway
2. Here are the core components are Microservices Architecture:
   • Clients: The client apps need to consume functionality from multiple Microservices. Thus, the client needs to handle various calls to Microservice endpoints if that consumption is directly performed.
   • Identity Providers: The services are lightweight & fine-grained. The identity Microservice must allow both server-to-server & user-driven access to identity data. Microservices enables applications to be created through a collection of loosely coupled services.
   • API Gateway:It is responsible for request composition, routing, & protocol translation. It provides a custom API to each application’s clients. For most Microservices-based apps, API Gateway implementation is crucial for a single-entry point into the system.
   • Messaging Formats: Microservices communicate through synchronize or asynchronized messages. Synchronous like HTTP is a synchronous protocol. The client sends requests & waits for a response from the service. The message sender or client code usually does not wait for the response.
   • Databases: Microservices had a private database to implement respective business functionaries & capture data. Microservices databases get updated through their service API. Microservices are carried to any remote service that supports inter-process communication for different tech stacks.
   • Static Content: After Microservices communicates within themselves, they deploy static content to the cloud-based storage service that can deliver directly to clients through a Content Delivery Network.

Answer:

1. • Advantages:
     • Improves scalability
     • Fault isolation
     • Localized complexity
     • Boost agility
     • Simplifies debugging & maintenance
     • Smaller development teams
     • Better scope for tech up-gradation
   • Disadvantages:
     • Much Complicated as a whole
     • It needs precise pre-planning
     • Modular dependencies are difficult to calculate
     • It has less control over the third-party applications
     • Modular interdependencies are hard to track
     • More chances for malicious intrusions
     • Complete end-to-end testing is tough
     • Deployment challenges exist
2. • Microservices Advantages
     • The smaller code base of Microservices is easy to maintain
     • It is relatively easy to scale an individual component
     • It fosters technology diversity so we can mix different frameworks, libraries, & frameworks, etc
     • Supports fault isolation which means a process failure will not bring the entire system down
     • There is better support for parallel & smaller team
     • Independent deployment
     • Reduces deployment time
   • Microservices Disadvantages
     • It is difficult to attain consistency across services
     • ACID transactions don’t span multiple processes.
     • Distributed systems are difficult to debug & trace the issues
     • Requires more for end-to-end testing
     • Cultural differences across teams like Development & Operational working together in the same team.

Answer:

1. In the Monolithic Architecture, all application’s software components are packed & assembled tightly.	SOA or Service Oriented Architecture refers to a collection of services that communicate with each other through activity coordination & simple data passing.	Microservices Architecture means a collection of small functional modules. These modules are independently scalable, deployable, target specific business goals, & communicate with each other over the standard protocols.

2. • Monolithic Architecture is like a big container wherein all application software components are tightly packaged & assembled together.
   • SOA (Service-Oriented Architecture) is a collection of services that communicates with each other. The communication can involve simple data passing or could involve two or more services coordinating some activity.
   • Microservice is the architectural style that structures an application as a collection of small autonomous services modeled across a business domain.

Answer:

1. Domain-Driven Design means an architectural style based on the (OO)Object-Oriented Analysis Design concepts & principles. It helps in building a complex system by connecting related components of a software system into a continuously evolving system. DDD (Domain-Driven Design) is based on three core principles:
   • It focuses on the core domain & domain logic.
   • Base complex designs on the domain models.
   • It collaborates with the domain experts on a regular basis to improve an application’s model & resolves any emerging domain-related problems.
2. Domain-Driven Design or DDD is a software development approach that revolves around solving complex domain models. The solution revolves around a business model by connecting the implementation to the core business concepts. Here are the core fundamentals of Domain-Driven Design:
   • It mostly focuses on the domain logic & the domain itself.
   • Complex designs are based on the domain’s model.
   • It improves a model’s design & fixes any emerging issues by constantly collaborating with domain experts.

Answer:

1. • Coupling:It denotes a relationship between module A & module B. Any module can be highly coupled or dependent, uncoupled & loosely coupled with other modules. The best coupling is the loose coupling achieved through the interfaces.
   • Cohesion: It denotes is a relationship between multiple parts within a module. A module with high cohesion means it can perform a particular task with high efficiency, without communication with other modules. High cohesion improves the functional strength of a module.
2. • Cohesion: It is a link or association between two or more parts within the module. If a module has high cohesion means the unit can carry a convinced task with the greatest competency on its own, without communicating with other modules. High cohesion boosts a modules’ s functional power.
   • Coupling: It is the relationship or link between module A & module B. Any module can be tightly coupled, loosely coupled, or uncoupled with the other modules. The best coupling is movable or loose coupling accomplished through the interfaces.

Answer:

1. Distribution transaction has multiple network hosts. These transactions are handled by a manager that keeps a check on handling & developing transactions. If a transaction involves more than one peer, the transaction manager of each peer communicates with each other through a superior or subordinate relationship. Likewise, the resource manager handles resources that also coordinate with the distributed transaction coordinator for transaction isolation & atomicity.
2. Distributed Transaction that involves two or more network hosts. Generally, hosts provide the transactional resources, where a transaction manager creates and manages the global transaction that encompasses all operations against the resources.

Answer:

1. Contract Testing ensures that both explicit & implicit contracts of Microservices work as expected. There are two perspectives to contract testing, i.e., Consumer & Provider. The consumer is the entity using Microservices, while the provider is the entity providing the service.
2. Contract testing refers to a test at an external service’s boundary that verifies if it meets the contract expected by the consuming service or not. It does not test a service’s in-depth behavior. Instead, it tests service call inputs & outputs containing the required attributes & response latency, throughput within the allowed limits.
3. Contract Testing is a writing test to ensure whether a Microservice’s implicit & explicit contract will work as advertised. It has two perspectives, consumer & provider. Contract testing is applicable anywhere where there are two services that need to communicate – like an API client & the web frontend.

Answer:

1. Melvin Conway introduced Conway’s law in the late 1960s. It states that “any organization that designs a system will inevitably have to produce a design whose structure is an exact copy of the organization’s communication structure” the law mainly applies to modular software systems.
2. Conway’s law implies that “any organization that designs a system will inevitably need to produce a design with a structure as a precise copy of that organization’s communication structure.”

Answer:

1. Mock generally refers to a dummy object in which some features are set initially. Its behavior depends on those features, which are then tested. On the other hand, Stub is an object that helps in running a test. It functions in a fixed way under certain conditions. The hard-coded behavior of Stub allows it to run the test.
2. A Stub denotes an object that facilitates running the test. It has hard-coded fixed behavior (in certain conditions). Any other Stub behavior is never tested. In contrast, a Mock means a dummy object wherein certain properties or features are set initially. Mock behavior depends on the set properties. Also, its behavior can be tested with properties.
3. A Mock is a replica object where some specific features are set initially into it. Its behavior mostly depends on the features, which are then tested.
   A Stub is an object that helps in running the test. It functions in a fixed mode under certain conditions. Stub’s hard-coded behavior helps it to lope the test.

Answer:

1. Mike Cohn’s Test Pyramid is a type of automated test needed for software development. The Test Pyramid is a metaphor that represents the grouping of tests on the basis of their granularity. The Pyramid indicates what type of tests should be applied to the different levels.
   Mike Cohn’s Test Pyramid has three layers:
   • Unit Testing
   • Service Testing
   • User Interface (UI) Testing.
   Two things to be derived from  Cohn’s Pyramid are:
   • Define tests with different granularity
   • The higher level you reach, you should have fewer tests.
2. Mike Cohn provided the Test Pyramid model, a type of automated test required for software development. As per the Pyramid, the no. of tests at the first layer should be the highest. While at the second layer, the number of tests should be less than at the unit test level but more than at the end-to-end level.
3. Mike Cohn’s Test Pyramid describes automated tests needed for software development. There are three levels in the Test Pyramid as follows:
   • Pyramid’s first layer is for Unit Tests, a result of TDD (Test Driven Development). It lays at the bottom of the Test Pyramid.
   • Pyramid’s second layer is for Service Tests that help to test the services under different inputs directly. These tests also verify an interface provided by the service against a client’s expectation.
   • Pyramid’s third layer is User Interfaces or End-to-End tests. Such tests run against the whole system, including User Interface, Frontend, or third-party clients. The purpose of UI tests is to verify the actual production code. It lays at the topmost layer of the Test Pyramid.

Answer:

1. Canary releasing refers to a technique to introduce new software versions by rolling out an updated version to a small set of users before rolling it out to the entire infrastructure & making it available to all. It is named after the canary releases that alert miners in the coal mines when the toxic gases reach dangerous levels.
2. Canary Releasing is an effective technique to minimize the risk of introducing a new software version in production. It is done by slowly rolling out the updates to a small subset of users before providing them to the entire infrastructure & making it accessible to everyone.

Answer:

1. Two-factor authentication demands two rounds of authentication for an account’s login process. Entering a username & password is the one-factor authentication. While username, password authentication, & mobile number or a secret key can be considered two-factor authentication.
   Below are the different types of credentials you can use for two-factor authentication:
   • Something you may know like a pin, pattern, or a password
   • Something you have like your phone no., OTP, IDs, or ATM No.
   • Something you’re like biometrics or voice authentication.
2. There are three types of credentials required to perform two-factor authentication.
   • The things you know, such as a password, pin, or screen lock pattern.
   • A physical credential you’ve in a third-party device like ATM no., OTP or phone no. or an ATM card
   • Your physical identity like voice authentication or biometric security, eye scanner or fingerprint.

Answer:

1. NDT or Non-Deterministic tests are unreliable tests that sometimes pass & sometimes fail. When the tests fail, they are re-run to pass. One can eliminate Non-Determinism from tests in the following ways:
   • Asynchronous
   • Quarantine
   • Resource Leaks
   • Remote Services
   • Isolation
   • Time
2. NDT stands for Non-Deterministic Tests. Such tests are unreliable that sometimes pass & sometimes they fail. When Non-Deterministic tests fail, you re-run them & they pass. Thus, the results of such tests are not consistent. To remove the non-determinism from tests, follow these methods:
3. Quarantine: It’s better to separate (NDT) Non-Deterministic Tests from the rest of the suite. It helps to identify which test group is healthy and which one is unhealthy. The process is called Quarantine of NDT or Non-Deterministic Tests. You can put all NDTs in a separate suite. Over a period, you can start resolving issues with the separated suite while the healthy test suite keeps running for each build.
4. Asynchronous: If your test relies on other services for an asynchronous call, the results may not be correct always when the other service is down. Once you identify that the asynchronous call is the root cause of your problem, you can create the Test Double for that asynchronous call to solve it.
5. Remote Services: Some tests depend on remote services that are not up all the time due to which the tests do not behave consistently. So, it is better to create a Test Double or stub for remote services. It helps to rule out unnecessary dependencies on the remote services.
6. Isolation: Often, tests run in an unclean environment in each build. The files remain from the previous run in the environment. Thus, for a consistent run of tests, each build must clean the environment before running a test; thus, tests should run in that environment after the cleanup.
7. Time: Some tests depend on the time of the day, like business hours. Whereas developers run builds at any time of the day. In such cases, any test depends on the days’ time that gives a different result at different times. To solve this, you can introduce Stub for the system clock, so you pass the time of the day to your environment & start the test.
8. Resource leaks: If you have a resource leak, then your tests will start failing at a particular time when the resource usage exceeds the maximum limit. In such cases, you should implement a Resource Pool to control the resource limits, then run tests with a smaller no. of initial resources. It can help in identifying any inconsistent results due to Resource Leaks early in the development stage.

Answer:

1. Microservices are based on a concept where all component services interact with one another to complete the business functionality. It requires each Microservice to have an interface. RESTful APIs provide a logical model for building interfaces. It is based on the open networking web principles. Thus, it makes Restful APIs a crucial enabler of Microservices.
2. A Microservice Architecture is based on the concept where all services interact with each other to build the business functionality. To attain it, each Microservice needs to have an interface. It makes web API an essential enabler of Microservices.  Being based on the web open networking principles, RESTful APIs provide a logical model for building interfaces for various Microservices components.

Answer:

1. Eureka is also known as the Netflix Service Discovery Server. It uses Spring Cloud, so it is not heavy on the app development process.
2. Eureka is also called the Netflix Service Discovery Server. It uses Spring Cloud and is often considered the most-used setup for starting a service discovery. It isn’t much heavy on the app development process, which is why developers prefer to use it.
3. Eureka refers to an open-source tool by Netflix for locating Microservices so the load balancer can discover services & provide fail-over options to the middle-tier servers. Eureka plays an essential role in the load balancing architecture. It can help in identifying the list of Nodes in the memcache ring. It provides additional metadata information about the services. Eureka helps in fast service rollback in case of failure.

Answer:

1. Tasklet denotes a simple interface with one method to execute. A Tasklet can be used to perform single tasks such as deleting files, running queries, etc. In Spring Batch, the Tasklet is an interface used to perform unique tasks like cleaning or setting up resources before or after a step execution.
   Spring Batch deploys a ‘Chunk-Oriented’ processing style within its most common implementation. Chunk Oriented Processing means reading data at a time and creating chunks that will be written within a transaction boundary.

2. Item	Chunk	Tasklet
   Components	It consists of three components, mainly Item Processor, Itemwriter, & ItemReader.	It is consolidated in a Tasklet.
   Transaction	A certain no. of records is processed by issuing an intermediate commit. It can be processed through specific machine resources despite the data count. If an error occurs in between, then both processed data & unprocessed data will get mixed.	The data is entirely processed by the batch commit. The user needs to implement intermediate commit. If data to be processed is large, the machine resources may get exhausted. If any error occurs in the midway, only the unprocessed data gets rolled back.
   Restart	It can be restarted on the basis of record count.	It cannot be restarted on the basis of record count.

3. Parameter	Tasklet	Chunk
   When to use	Tasklet processing is used when a job to be run is a single granular task.	Chunk-oriented processing is done where the job to be run is complex and includes executing tasks like writes, reads, the processing, & transferring data.
   How it works	There is no aggregation & only the task gets executed.	It includes reading an input & processing it based on the business logic, then aggregating it till it reaches the commit interval & finally writes the chunk of data output to the database table or file.
   Usage	It is not used commonly.	It is the most common way of executing steps.

Answer:

1. When an exception occurs while processing the HTTP request, you need to catch the exception in your controller or service & manually return an appropriate ResponseEntity. Following are some thumb rules for exception handling:
   • For the exceptions, you write, add @ResponseStatus.
   • For all other exceptions, utilize the SimpleMappingExceptionResolver instance or implement an @ExceptionHandler method on the @ControllerAdvice class.
   • For the Controller-specific exceptions, add @ExceptionHandler methods to the controller.
   Note that @ExceptionHandler methods on a controller are always selected before the @ControllerAdvice instance. It is undefined in what order ControllerAdvices are processed.
2. Exception handling is the utmost part of web services development. When something goes wrong, or in case of some failure, you would want to return a good explanation of what went wrong to a service consumer. Also, you may not want the service to crash without returning anything useful to the service consumer. One can deploy Spring Boot as it provides good default exception handling.

Answer:

1. As RESTful APIs is based on the concept of open web networking, it provides the most logical model for building interfaces between the several components of a Microservices Architecture. RESTful APIs can be accessed in the following two ways:
   • By using a load-balanced REST Template.
   • By using multiple Microservices.
2. You can access Restful Microservices by using two methods as below:
   • Load Balanced Rest template.
   • Multiple Microservices.

Answer:

1. Microservices apps collect independent, smaller, & functional modules with different data resources, developed in different programming languages, & running on different operating systems. It makes testing of Microservices a very difficult task as different modules need to be tested individually. There are three common procedures to test Microservices:
   • Code Scanning: To ensure each line of code can be replicated & is bug-free.
   • Flexibility: The security protocols need to be flexible as per the system’s requirements.
   • Adaptability: The security protocols also need to be adaptable to malicious intrusions.
2. You will need to test all modules of Microservices independently, and there are three common procedures to do that as follows:
   • Code scanning: To ensure every line of code is bug-free & can be easily replicated.
   • Flexibility: The security solution must be flexible so it can be adjusted according to the system requirement.
   • Adaptability – The security protocols should be adaptable & updated to cope with security breaches or new threats.