Synchronous vs Asynchronous Web services

• Microservices can Communicate with each other into ways synchronous communication and asynchronous communication.
• Synchronous web services
• In synchronous call, if you are making any request, then you will have to wait till the response, you can’t do any Other thing Until you will not get the response.
• Supports both SOAP & REST Web Services.
• Imagine yourself waiting at ticket counter. You ask the counter guy for the ticket and wait on the window until he gives you the ticket.
• Easy to implement
• Easy to test
• Easy to debug
• Blocks processing so it becomes slow due to waiting
• Caller is blocked until the response is received.
• High coupling between services.
• A service should be get in loop for any changes happening in another service.
• Versioning should be maintained
• Strong contract
• Backward compatibility
• reliable due to response
• Most communication paradigms are based on HTTP like REST, GraphQL & GRPC
• Servers need to be proactively provisioned five peaks.
• Servers need to be readily available to handle the incoming requests.
• Risk of Cascading failures.
• To mitigate this we need circuit breakers.
• When should you use synchronous communication? 
• When you cannot move on.
• You need result before you move forward.
• Database Queries
• API responses
• When you want real time response
• Chat 
• Checkout
• When it will take relatively less time to compute and respond.
• Asynchronous web services
• In Asynchronous call, if you are making any request, then you don’t need to wait for the response and you can perform any other task.
• Supports only SOAP Web services.
• Now imagine a doctor’s office. You go, put your name down and wait until the receptionist tells you that doctor is ready for you.
• There are some services in an architecture which can run independently that is other services don’t depend on their response like mailing service and analytics service.
• Other services can work parallels with these which requires asynchronous communication.
• To pass data to asynchronous services we use a Message Broker.
• In message Broker we use queues
• Each asynchronous service listens to a Queue in message broker.
• Interaction between services is in exchange of text message via a Message Broker.
• Once response from a synchronous service is received we pass the message to respective queues.
• We can also perform asynchronous service operation based on callbacks.
• We can use callback methods once the response is ready with the service meanwhile we can process other services.
• The Messages are buffered in the broker and the consuming services will consume them when it can.
• If the consuming service is down, the messages will be consumed when the service comes back up again. So, no cascading failure.
• Difficult due to message Broker
• Difficult to test
• Difficult to Debug
• It’s harder to track the flow of communication.
• Non-blocking
• Fast
• Services don’t need to wait for the response.
• System can handle surge and spikes better.
• In case of a surge, the messages will Pile up in the Broker but there will be no difference in user experience.
• The consumer service would need to scale up to Clear the backlog.
• There is no need to proactive scaling of consumer service.
• Upon surge the messages will queue up but there will be no difference to End User.
• No load balancer is required, so no additional Netwerk hop.
• No request drop or data loss.
• Since we have a message buffer there is no request loss the messages pile up and the target system eventually catches up.
• loose coupling
• Sender and receiver services can scale independently.
• Not reliable as we don’t get immediate response.
• You cannot have a strongly consistent system with brokers and hence you have to be OK for the messages to be eventually consumed.
• Broker is a single point of failure.
• The message broker is the backbone of the system, hence we need to be super cautious about it. The broker we use should be horizontally scalable.
• A few message bookers are
• Rabbit MQ, SQS, Kafka, kinesis, google PubSub
• When should we use asynchronous communication?
• When delay in processing is OK
• Example notifier, analytics, reporting.
• When the job at hand is long-running
• Example provisioning a server, order tracking, DB backups.
• When multiple services need to react to Same event.

Prefer Composition Over Inheritance

• Inheritanceis tightly coupled.
• Inheritance is basically used for polymorphism which can be done in other ways to.
• Generally over a time we duplicate our code in inherited services across project which is good once or twice but if it happens third time then we need to rethink our strategy. This is also called as “The rule of thirds”.
• For example if we have Following services in our project
• Access control
• Publish subscribe
• Workflow
• Common components
• Entity master
• So we might be adding same function for access control in publish subscribe as well as workflow service.
• Sometimes it is not good to share code among various projects.
• A base class should not have methods that are not required by descendants.
• Same class may be at different level of inheritance in different projects.

• We might be exposing functionality to descendants that we don’t want to expose.
• Instead of putting all the different configurations into one file and inherit it we can distribute them in different classes.
• Message Broker Settings
• Postgres SQL settings
• Storage account settings
• We can use composition of these classes in our project. So each class will have only configuration that it requires.

• In the above example we have inheritance of only reusable code but for different settings we are using composition. So no Services code is with each other and each service has only required code.

IoT

Q What is the difference between wireless sensor networks and IOT networks?

Ans : IoT exists at a higher level then WSN. In other words, WSN is often a technology used within an IoT system. A large collection of sensors, as in a mesh network, can be used to individually gather data and send data through a router to the internet in an IoT system.