RPC vs Messaging: When to use which?

hey everybody it's derek martin from codopinion.com when should you choose synchronous or asynchronous communication when interacting with another service should you use http to send a synchronous call or should you use a message broker and prefer asynchronous messaging with say something like event driven architecture i'm going to break this down on how i think about it whether you're using a command or a query where you're sending the message from and to and how resilient to failures do you want to be so i'm talking about synchronous calls i'm really referring to things that you may expect of using an http api where you're sending an http request to get back some response a request response this could also be something like grpc or anything that's rpc related so where i think about you're actually going to do this are interacting with third-party services usually because you don't control them you don't own them there may be things you need to integrate with and most times these are going to be things that you have to communicate synchronously with second is infrastructure this could be things like your own database these are do things that you're a part of your core of your application but they could be like a cache a database and then lastly the place most obvious is when you're making a request from the client to your server to get data but that part is an interesting one because it depends on whether you're making a command or a query so i'm talking about asynchronous communication using messaging in a message broker i'm really advocating communication between your own services services within the overall system so this could be that you have a billing service that's communicating with a sales service or an accounting service but those communications are done all asynchronously through messaging this could be events they could be commands but you're doing everything asynchronously this means that you have to have well-defined boundaries within your service meaning a server should have all the data it needs to operate autonomously it shouldn't have to make a synchronous call to another service to get data it should have all the data it needs and then lastly it could be the application itself or service if you have a service you can use messaging even to communicate with your own service if you have a monolith you can do the same thing you can use messaging to asynchronously decouple code so commands and queries play a big role in deciding whether you want to be synchronous or asynchronous so let's first talk about queries because this is the question i probably get the most which is okay i use messaging but how does that work when you're interacting with a ui well you're not using necessarily messaging there so if you have a client ui and then it needs to send a request to some service or application yes at that point you're making that synchronous call that's going to be a synchronous call likely over http and then your service whether it has to interact with a database if it's going to do that obviously that's going to be synchronous and it's gonna basically build its result and then send that back to the client so there's nothing wrong with necessarily this being synchronous when communicating between services however i recommend asynchronous messaging this means that you have a service when something's happened to it it's gonna publish an event for example that to the message broker and then you're going to have maybe zero one or many different services that are going to consume that event that means that the message brokers gonna push that message to your other services so they can consume them so they can react to things that have happened within other services the reason i don't recommend synchronous calls like http to communicate between services is because of the complexities related to latency availability and resilience if you want more info on that check out my video about rest apis and micro services and things you need to be aware of a small example of this though is let's say i have a client ui and a service that needs to talk to a third party say there's a third party service could even be a database anything that we're making another synchronous call to is what happens when we make the call but there's a failure let's say it's a transient issue let's say that third party service or database or whatever the case may be that we're interacting with isn't available yes you can have built-in retries exponential back-offs but if all that fails what do you send back to the client do you just send back an error message to the client that there is a failure if that third-party service that you have is critical to you are you just going to be down as long as they're down now this is very different if the originating request on how we need to process something is starting originating from a message broker and not a client ui that means that if we have a message broker that sends our service a particular we're consuming some particular message that once we're doing that we need to interact with that third-party service but that third party service is unavailable well this is very different now because we can retry we can do our exponential back offs and if that's not fail if that's still failing we don't need to necessarily return an error to our client because we have no client our client is technically the message broker so at this point we could decide to retry later put our message into a dead letter queue so we can process it later investigate later but necessarily from an end user's perspective nothing really ever failed because they weren't aware that we were even processing the message for example let's say we have a client ui that's making a request to our service to place an order that is a synchronous call to our app service to process that order and to create the order but instead what we're going to do instead of interacting with our third-party service or our database rather what we're going to do is we're going to create a message send that to our message broker a message queue and then we'll just disconnect from our client saying thank you your order has been placed but we actually haven't processed the order we haven't created the order yet all we've really done is create a message in our message queue which asynchronously at this point we can then interact with our third-party service and if it's unavailable that really isn't an issue we can retry as mentioned put it to our dead letter queue if we retry and it works at that point our actual order has been processed and has been placed but if our third-party service is down we never lost the order we just weren't able to process it right away so then oftentimes the question is well then how do you let the client know that something's actually been processed after the fact asynchronously well you can do that and i'll illustrate an example in aws how this happens all the time so let's say that our client ui is making a synchronous http call and yes we're doing the same thing as before instead of processing it right away we're just going to create a message that represents that request what we want to perform whatever action it is we put that to our message broker to our message queue we tell the client we're good we then process it completely asynchronously and once we finish processing it we can then go back and use something like a push notification something like signalr with websockets to then push down to the client to tell them that something is actually finished and you can do this asynchronously a good example of this is in the aws console for ec2 is i have a running instance now if you haven't used aws you can probably relate this to any other cloud service if you're thinking about a vm is when i go to stop this instance when i send the the actual request that's going to make an hp request back to their service i don't have it's not the request isn't going to take minutes and it's not going to be blocking in terms of waiting it's actually going to just finish that request very quickly and then asynchronously sent updates or polling back to the browser to actually tell me it finished so if i go to stop this instance it says i successfully stopped but i haven't really stopped if i refresh right now we can see that it's stopping it hasn't stopped i'm able now to interact with the console and it's not blocking i don't like not sitting there waiting for it to finish and stop because what likely happened is when that request was sent it created a message a command to a message queue that's processed separately asynchronously and then in the aws console here it's actually polling to see status changes for my actual instance for when it's actually stopped it will show that it's actually stopped but it wasn't blocking these aren't all synchronous calls happening from the client to the server to some other service to actually stop my instance so the first thing to think about if you're making a synchronous call is it a command or is it a query if it's a query and it's originating from a client or a ui then this makes sense that it's going to be a synchronous call because you want a response however if you need to make a synchronous call from one service to another service to get data i take a look to see if my boundaries are correct and for a command again where did it originate from if it's from a client ui do you fully need to process that message to give them back a result or like the example in aws can you create a message and likely process that asynchronously and then notify the client separately after it's been processed that it's complete if you found this video helpful please give it a thumbs up if you have any thoughts or questions make sure to leave a comment and please subscribe for more videos on software architecture and design thanks you

Channel: CodeOpinion

Views: 6,203

Keywords: synchronous vs messaging, software architecture, software design, cqrs, event sourcing, design patterns, software architect, soa, microservices, message queues, kafka, event bus, event driven architecture, azure service bus, rabbitmq, distributed transactions, service bus, mass transit, nservicebus, message queue, message queuing, messaging patterns, service oriented architecture, microservice architecture, domain-driven design, enterprise service bus, Synchronous vs messenging

Id: LMKVzguhFw4

Length: 9min 9sec (549 seconds)

Published: Wed Jul 07 2021