First time in life I am binge watching an educational video series. There are 100s of beginner tutorials on RU-vid and no one talks about these extremely important concepts which we actually use in our projects. Thanks you so much for the hard work and efforts you have put in to bring up these videos to us 🙂🤗
How to ensure high availability in case a queue goes down? also, if you can also point out the latest tools and libraries that are used to achieve these concepts, it will be really nice for the audience to do a hands on.
It's not okay to use a Queue if you want to send an update to multiple microservice, we use PUB/SUB. like kafka is a pubsub where multiple consumer group can read the same message but SQS or rabbitMQ is a queue where a message can be retrieved only once unless you send it to multiple queue for each microservice which is a overhead for the producer microservice
WOW! First video of yours that I have watched and it’s Nice (explanation). Please keep adding more videos on SpringBoot Microservices (with detailed architectural explanation on the board).
Hi I am concerned about how MS1 gets data back from the dependent microservices? Should MS3, MS4, MS5 have an output queue too, or is it going to be a HTTP call? Please reply
how does the data come back from requested services? is it coming back in same way they will write to MS1 queue? How do we handle responses if we have to return data immediately?
docs.microsoft.com/en-us/azure/architecture/patterns/async-request-reply The above link might help in understanding how the response may come from other microservice( say microserviceN) after the microservice1 adds it to queue of microserviceN.
Is separate queue is required for each service? And what is the issue with using single clustered HA database, that I didn't get it, can you provide any disadvantage article link?
When we send messages through topics in Apache Kafka, are messages persisted? In other words, say if one of our micro services was not available when the message was sent, will it be able to get the same message from the topic when it becomes available again? How do you ensure that a message in queue is persisted / put back in queue, when micro service fails due to a network failure during processing of a message? How are you returning the response back by using queues? MS1 puts in a message in a queue, and MS2 processes it, but how does MS1 know processing is complete? How does original request get handled from the client ?
though its late , but still ...try reading about consumer delivery semantics : dzone.com/articles/kafka-consumer-delivery-semantics . Its a simple config that needs to be changed .
Good explanation! BUT! I think there is some misunderstanding. Even we have all this queues in the system we still can do synchronous requests. 1. There is no a good explaination why it's really async. It became async depends on how MS1 is implemented but not how communication between services is implemented. 2. Why API became faster? If we take a single request it will take more time, just because we have extra components (like queues) in the system and that is why we will have extra latency. So, a single request will take more time. But if we are talking about 1000 request per sec it may be faster because while MS1 is waiting for response from MS2 it can handle second request in parallel. And in this case to have all this queues is not required. 3. If we are talking the case when we put a message into the queue and do not waiting for the response - in this case it is faster. Yes, it will be faster, but without response. But we need a response. That's a point, we anyway needs to wait for a response the same as sync request and it does not depend how communication is implemented. I'm a .net developer and thinking about async/await approach (similar you have in javascript). It does not require any queue or even second microservice. It depends how actual function makes a request.
Even in case of async/await approach, the remaining code of MS1depends on MS2 response, then it doesn't make sense to implement async await right! it should be synchronous. But, if remaining code of MS1 doesn't depends, then it makes sense to implement async await.
@@Lokeshsanapalli1729 If the code should should be synchronous then the queue approach won't work as well as you don't know when you get the response from the other microservice.
It's nice to say that you should use asynchronous services and that the calling service is not dependent on the ones it's calling but what if it is? Isn't that why they have circuit breakers with fallback procedures? You can't say a banking app that is calling a microservice to determine the bank balance can just wait until some service reads a queue and decides to process the request. It needs the information before it can proceed.
Thank you for the video! I have a question though! What about the sharing between 2 different microservices in terms of foreign keys, join tables and etc.? If 1 microservice for 1 entity/table needs to have a foreign key on another, it needs a direct reference to that table and so they should be in the same database
So I've been taking a CQRS design course using Axon and the default message broker which Axon uses for inter microservice communication. The answer to my question is simple, but questionable to me, albeit used in enterprise applications. Basically, in Axon-centric architecture with CQRS, we have references to ID's/primary keys of another table, but they are NOT foreign keys. Instead of using foreign keys to ensure dta integrity on the side of the DB, we rely solely on our code/axon to ensure that the value entered in the column which holds foreign id's is storing only ID's that truly exist in that other table, if that makes sense. Seems fundamentally flawed from the perspective of DB management, IMO. I personally do not think this is a perfect solution, but it's apparently used a lot now due to the overwhelming call for "de-coupling"...
Thank you for your explanation. You said that Microservice 1 is waiting for the answer from Microservice 2 in the first architecture, but in the 2 you don't. What if you need an answer from 2 Microservice than you can't use 2 pattern or what?
Hi Naren! Thanks for your videos always. I really appreciate it. One question. You mentioned that one of the advantage of messaging queues are "no service discovery" because we can hard code the address of the queues. But it's possible that queue instances can be taken down and spun up again. it seems like there seems to be some kind of entity to let the services know the address of the queues. Can you share more thoughts about this?
Thanks guy, how does it work if a service needs info from another service. For exam, payment needs credit card info to purchase. Or when we request a "course" we also want "teacher" info included in response.
Thanks, very nice explanation. I am wondering if we can have only one centralized queue and than services to respond to it if they are subscribed to that event type.
Can't really have a central queue because if one service goes down then you can't deque it, you'll be creating a bottleneck for the rest of the ms that are up.
It's strange that you're showing availability benefits of queues by comparing the request/response pattern between micro service 1 & 2 where 1's response to the client depends on the response from 2 to 1 and the message queue pattern where no such relationship exists. In the latter, what happens to micro service 1's response to the client if micro service 2 is down? Wouldn't there be a timeout?
If you look at the diagram he draws,he doesn't get a response from microservice 2, that can be acted on by microservice 1. Microservice 1 should just return a 202 status code as response.
One thing to add, if there are too many internal communication between to micro services, those two micro services should not be breakdown into 2 micro services in the first place.
does this include if 1 table needs foreign key on another? How to have CQRS pattern with database per service if the 2 tables require foreign keys, or, join table ?
How Synchronous microservices talk to each other on cloud i.e AWS. Suppose there are 2 microservices A& B which are deployed on AWS ec2 instance. I cant hardcode B endpoint in A microservice. Bcz everytime Ec2 instance started , the IP gets changed.
Hi Narendra, thanks for the video. One question - For async / queue type of communication, you place an order and the order is created. But after that, I want to show the bill to the user immediately. But billing task has been posted to the queue. Should one poll to get the billing details? I am thinking about from the UI / API call perspective. I make a network call to place the order and then how do I get a response with billing details?
I got the exact same doubt about the response to the current api call. Can you please comment here in case you found the answer to your question by now.
Several gaps in this video: 1) Asynchronous communication using queues, is fault tolerant, because the called service (or the queue consumer) can die and the new instance can continue without error or data loss. However, this can also be achieved by using a retry policy with synchronous http/rpc service calls. 2) Queues can also be used for call and response pattern, using a send queue and receive queue, instead of a single send queue. Masstransit library implements this pattern using Rabbitmq. 3) Lags in making http calls can be mitigated by making async http/rpc calls. Several languages/runtimes like C# and Node/Javascript already have this built in, the async/await pattern. This pattern can achieve huge throughput performance gains.
How do you make sure Atomic Transactions in order to have consistent data? For example Service A stores data and publishes an event (order.created) to the Message Broker, but the MS is not available, what happens here, should I do a rollback in my transaction or store the events in my DB and try again? Thanks.
Asynchronous communication does not solicite a response from the downstream service. Expecting a response is a synchronous activity and must use synchronisation communication.
That's pretty tricky, but usually, if you have async calls, and expect information to be returned some time later (maybe hours or days later), you would send some kind of correlation or transaction id. When receiver will pick up your message (from some queue), process it and send you the response, it will add such correlation id, so that receiving service knows, to what user/transaction to "attribute" that response. After receiving it, your "initial caller" service could continue executing transaction, as it was intended. But you'll have to handle some kind of persistence between your initial async call, and response to it, and recovery after response has been received.
I also didn't understand that. It seems 2 completely different uses case are being compared. First one was how Microservice 1 and 2 will talk to each other , and the second is just if Microservice 2 wants a notification. How do 1 and 2 talk to each other asynchronously?
@@altereago1 there can be multiple ways for 2 services to talk asynchronously. *1. Through message brokers like Apache Kafka:* Here, Service 1 (S1) doesn't talk directly to Service 2 (S2). Instead, it puts some event in the message broker. When S2 processes the event by consuming what S1 produced, it can produce another (response) event in the message broker. This response event would then be consumed by S1. *2. Through callbacks:* S1 places a callback in the API call. This callback would be called by S2 when it wants to return back the response.
Microservice 1 still has to wait for the response from microservice 2 because it is waiting for the data, according to the arrows on the synchronous diagram. If you are just sending it info to be consumed and, maybe, written to persistence memory, then that is a different story.
I have a question. That you are saying that "no need of service discovery" , but i thing service discovery is used by LB(AG) in case of asynchronous call also ? (how can you identify the services replicas (nodes) address).
Yes. What he is saying is each service do not need to use service discovery be aware of the network addresses of the other services. That is taken care of by the message queues
Hi Narendra, how do you monitor state here then? Eg. when I call the billing service, I need to store some of the computation I did during that flow somewhere. Now when the response event comes back, I have to pick up the data and continue the computation. How to do that here?
if your service are still coupled like this then its not the correct abstraction and you're still trying a monolithic paradigm. Basically a microservice should be as independent as it can and should have a defined responsibility
Dear All, Can anybody tell me how we can stabilize the one to many relationship between two microservices ? like service 1 : user microservice; service 2 : contacts microservice. and I want one user can have many contacts in arrayform.
Please do not use middle finger while pointing on whiteboard, its very offensive if you want to reach international audience. You use middle finger, pinky and index finger, pick one style and stick with it.
Your explanation is bad. Why exchanging data via queue is asynchronous? what is the advantage if we still wait for the result produced by another microservice whatever the protocol is - REST, RPC, or queue? And you blindly say that the communication over queue is faster while it is not at all necessary faster
