Microservices

How can we secure our micro-services?

• Application security
• User security
• Spring access controls
• Framework security
• Interaction with downstream services.

What is the difference between two phase commit and Saga pattern of micro services?

• 2 Phase Commit
• Centralised coordinator
• Synchronous communication
• Strong atomicity
• Less, flexible, single point of failure
• Slower participants wait
• Strong consistency, limited participants
• Saga
• Can be choreographed(events) or orchestrated(central saga)
• Asynchronous communication
• Eventual consistency, user compensating transactions
• More flexible, resilient, No single point of failure.
• Faster, independent operations
• Long running, Complex transactions, multiple services, eventual consistency

What is the difference between Asynchronous and synchronous micro service communication?

• 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.