This tutorial demonstrates migrating microservices from a TCP transport mechanism to RabbitMQ to improve system reliability and message handling. The instructor refactors existing NestJS services, updates Docker Compose configurations, and integrates new environment variables to support asynchronous communication and message queuing across the architecture.
Length 9:19
Captions English (Generated), Spanish (Auto-translated), French (Auto-translated), Korean (Auto-translated), Portuguese (Auto-translated), Vietnamese (Auto-translated) #rabbitmq #microservices #nestjs #docker #message broker #asynchronous #coding #software engineering #backend #refactoring
0:00 Okay, so next up, we're gonna look at using RabbitMQ as 0:04 our transport mechanism to communicate between our microservices. 0:08 Now, of course, right now we know that we're using the TCP transport 0:12 mechanism. 0:14 However, there are also some downsides to using the 0:16 TCP transport 0:18 opposed to an asynchronous messaging transport like 0:21 RabbitMQ. Now, to actually show the disadvantage of 0:25 using the TCP microservice, let's go to the payments 0:29 microservice, and in the payments controller, when 0:33 we receive the request to create a charge, let's immediately 0:37 throw a dummy error here so that we will always 0:41 throw an error and never actually create the charge. 0:43 And then let's go ahead and open up Postman to create a 0:46 reservation to see 0:47 what happens. So in Postman, I'll launch a request at the 0:51 auth/login route first with a created user to obtain 0:55 a JWT, 0:57 and then we'll go ahead and execute in a request 1:01 to create a reservation. So this is the typical payload that we 1:05 would have to create a reservation. 1:07 Now, of course, we're getting back a 500 internal server 1:10 error because 1:11 when the reservations microservice tried to reach out 1:15 to the payment service, we can see that it threw an error here 1:19 and the reservation service immediately failed. 1:22 So this is showing the problem with the TCP microservice. 1:25 There's no way to retry any sort of failed messages in our 1:29 system, and our messages can't be queued up one 1:32 behind one another. 1:34 So if we have a massive influx of messages into our system, 1:37 our system can become overloaded and we can't respond gracefully 1:42 if we need to retry a message. We immediately throw this 1:45 error and then this payments request is never retried because there's nowhere 1:49 to 1:49 actually save that message. Now, using an asynchronous microservice 1:53 like RabbitMQ, we have the idea of a queue that
The rest of the transcript is for members.
Sign in 