Technical Architect interview @ DoctorAnywhere

Hi friends,

In this post,I am sharing interview questions asked in DoctorAnywhere.

Question 1:

How does the communication happen in microservice architecture?

Answer:

In microservice architecture, client and services can communicate through many different types of communication, each one targeting a different scenario and goals. Initially, those types of communications can be classified in two axes.

The first axis defines if the protocol is synchronous or asynchronous.:

Synchronous Protocol: HTTP is a synchronous protocol.  The client send a request and waits for a response from the service. That's independent of the client code execution that could be synchronous(thread is blocked) or asynchronous(thread is not blocked and the response will reach to a callback eventually).

Asynchronous protocol: Other protocols like AMQP use asynchronous messages. The client code or message sender usually doesn't wait for a response. It just sends the message as when sending a message to a RabbitMQ queue or any other message broker.

The second axis defines if the communication has a single receiver or multiple receivers:

Single receiver: Each request must be processed by exactly one receiver or service. An example of this communication is the command pattern.

Multiple receivers: Each request can be processed by zero to multiple receivers. This type of communication must be asynchronous. An example is the publish/subscribe mechanism used in patterns like event-driven architecture. 

This is based on an event-bus interface or message broker when propagating data updates between multiple microservices through events. It is usually implemented through a service bus like Azure Service bus by using topics and subscriptions.

A microservice-based application will often use a combination of these communication styles. The most common type is single-receiver communication with a synchronous protocol like HTTP/HTTPS.

Microservices also typically use messaging protocols for asynchronous communication between microservices.

Note:

Ideally, we should try to minimize the communication between the internal microservices. The fewer communications between microservices, the better.  But sometimes, we need to implement communication between the microservices and critical rule here is that the communication between the microservices should be asynchronous.

If we implement synchronous communication between microservices, we have an architecture that will not be resilient when some microservices fail.

If our microservice needs to raise an additional action in another microservice, if possible do not perform that action synchronously. Instead do it asynchronously (using asynchronous messaging or integration events).

And finally if our initial microservice needs data that is originally owned by other microservices, do not rely on making synchronous requests for that data. Instead , replicate or propagate that data(only the attributes we need) into the initial service's database by using eventual consistency.

Note: Duplicating some data across several microservices is not an incorrect design.   

When a client uses request/response communication, it assumes that the response will arrive in a short time, typically less than a second or few seconds at most.

For delayed responses, you need to implement asynchronous communication based on messaging patterns and messaging technologies.

Question 2:

How to implement asynchronous message-based communication?

Answer:

Asynchronous messaging and event-driven communication are critical when propagating changes across multiple microservices and their related domain models.

A solution is eventual consistency and event-driven communication based on asynchronous messaging.

When using messaging, processes communicate by exchanging messages asynchronously. A client makes a command or a request to a service by sending it a message.If the service needs to reply, it sends a different message back to the client. Since it is a message based communication, the client assumes that the reply will not be received immediately and that there might be no response at all.

A message is composed by a header (metadata such as identification or security information) and a body. Messages are usually sent through asynchronous protocols like AMQP.

A rule we should follow is that to use only asynchronous messaging between the internal services and to use synchronous communication (such as HTTP) only from the client apps to the front-end services(API gateways plus the first level of microservices).

There are two kinds of asynchronous messaging communication: single receiver message-based communication and multiple receivers message-based communication.

Single-receiver message-based communication is especially well suited for sending asynchronous commands from one microservice to another.

Once we start sending message-based communication (either with commands or events), we should avoid mixing message-based communication with synchronous HTTP communication.

In multiple receiver message-based communication, we use a publish-subscribe communication and for that we can use an event bus interface to publish events to any subscriber.

Asynchronous event-driven communication:

When using asynchronous event-driven communication, a microservice publishes an integration event when something happens within it's domain and another microservice needs to be aware of it, like a price change in a product catalog microservice.

Additional microservices subscribe to the events so they can receive them asynchronously. When that happens, the receivers might update their own domain entities, which can cause more integration events to be published. This publish/subscribe system is usually performed by using an implementation of an event bus. 

Question 3:

You have two sticks and matchbox. Each stick takes exactly an hour to burn from one end to the other.

The sticks are not identical and do not burn at a constant rate. As a result, two equal lengths of the stick would not necessarily burn in the same amount of time. ow would you measure exactly 45 minutes by burning these sticks.

Answer:

0 minutes - Light stick 1 on both sides and stick 2 on one side.

30 minutes - Stick 1 will be burnt out. Light the other end of stick 2.

45 minutes - stick 2 will be burnt out.

That's all for this post.

Thanks for reading!!