What about cross service transactions?

@@n4870s Wait until next Monday. I'll publish a video that will go through one possible technical implementation on that subject.

Love the overview. Where is your followup video called for how to create Async driven events with a broker? I recommend adding it to the description of this one and maybe a link at the end of this video, thank you.

That video has not yet been done. It's still ok n my to-do list.

If a service is down and if it starts processing messages in a queue, it will eventually catch up.

@@DevOpsToolkit you are right, but also in many occasions the cathing up is more than a problem than an advantage, users keep resending the same request because they are not getting any response, and we should clear the messages before bringing up the service. I personally believe the fast feedback of sync communication is actually a great advantage.

Thanks

Thanks a lot for the feedback. Visualizations are new and, so far, we used them in only a couple of videos. I'll double down on them and use them more if they're helpful.

In this video, I'm experimenting with a new format. Typically, I'd explain architecture/process/etc. first, and then go through the technical parts and a demo. This time, I thought to split those so the next one will be one possible implementation of the ideas presented in this video. I'm still not sure whether having it together or split makes more sense so I'll do both approaches and see the reactions before I choose to stick with one or the other.

@@DevOpsToolkit splitting is a great idea, as you can explore different approaches/technologies to solve the same pattern (eg. Async integration by using threads/workers at application level, versus async event driven messages + choreography/orchestration) . I thought this one could be even longer, as the concepts are not easy to explain. Looking forward to it! 😍

@@denisstortidasilva3832 Such feedback is very helpful in deciding how to organize future material. Thanks. As for length... It's very hard to decide long long videos should be. When I make 30+ min videos, some people say they're too long. When I make them shorter, some say that they'd like them to be longer. That's also one of the things I want to experiment with. I'll try creating videos with more varied length (from a few minutes up to 45 min.) and see what has better reception.

@@DevOpsToolkit I like the new content. I work in a smaller company and I think that a lot of people in a smaller company may not think this is valuable. But I spend a ton of time integrating services and having good architecture between services is incredibly helpful. I use a lot of Google pub sub. As soon as you find yourself with 6 or 7 or 12 applications you need to take a step back and evaluate.

@@erikslorenz It's normal for smaller companies not to think about practices that are designed for bigger operations. The problems typically occur when something small becomes bigger and teams do not take time to "step back and evaluate" the new situation but just keep going.

It's coming next Monday :)

It's already recorded and is currently going through the editing and animations phase. It'll be published next Monday :)

I guess that not doing any marketing and not focusing on newbies leads to much smaller number of subs. I'm working on this channel mostly because I enjoy it and certainly not as a business so I'm not doing what needs to be done to increase subs.

You're not the only one that watches with increased playback speed. I do not think Darin ever watched anything at 1x :)

Typically, events should be idempotent so that multiple handlings of the same event do not result in multiple records. Otherwise, it's hard to guarantee that events will be processed in the first place. That's why we normally adopt the at-least-once approach. That being said, you can set up the backend of the event to guarantee that an event will be picked up by a listener only once.

@@DevOpsToolkit By "backend of the event" do you mean the message broker?

You're right. I meant message broker. I should stop writing messages over my phone while crossing a street :(

@@DevOpsToolkit I appreciate your effort :) Thank you for the answers

I can't answer that question without more info. What i can say is that direct communication is easier while events are more reliable abd scale better.

Sync communication is unavoidable. For example, a backend app needs to talk directly to the db.

It does, but not in the mode I used it. I used pub/sub while you want direct messaging.

If you need sync communication, any service mesh should do.

@@DevOpsToolkit what if the microservices are subgraphs in an Apollo Graphql Federation 2 ?

unfortunately, I haven't used Apollo 😔

Thanks a ton!

Try NATS.

I think I said that a couple of times. The fact that one protocol is synchronous does not mean that it cannot be used asynchronously, and vice versa. Now, it's quite possible that even though I said that, I did not explain it well. I'll do my best to improve the way I explain in the upcoming videos.

If you want to get something, that's a simple get from the service or, more often ,a database that has the info. Events are more about "i just posted this, whomever needs it, come and get it." Imagine it's Amazon that consists of many services and someone just added an item to the shopping cart. That specific service does not need to worry who else needs that info. It does not need to do anything but post an event knowing that whomever needs to do something with it will get it. It's about decoupling. Another example would be kubernetes itself. When you send a manifest to Kube API, an event is created. The API has no idea which controller is responsible to do something with it. Instead, controllers are listening to events and performing actions when it's one they are subscribed to. Otherwise, the API would have to have the logic of forwarding requests to a massive number of controllers or you, the user, would need to know which specific controller to talk to.

In that case you would probably talk to those services through a fixed endpoint like ELB or ALB.

@@DevOpsToolkit so u mean, instead of calling B microservice directly , we call load balancer which redirect our request to B. Right ?

Yes.

Example Hive mq for mqtt.

If you look at the performance of that request, you are right. But, if you look at the performance of the application as a whole or the whole system (especially at scale), waiting for responses is costly, especially if that means requests to multiple applications.

You can think of it like the difference between response time and throughput, especially under load. Sync calls are great, until they hit some threshold where all their threads are blocked waiting for an operation to complete, then they tend to explode. Synchronous operations are fine if you have a high certainty that they will be completed quickly. The issues can come if you have a chain of sync calls, as any point along that chain could get stuck / crash / etc. and force your sync calls to block until they time out. They also don't handle changing scale gracefully; if you have a number of requests in-flight and the system decides to scale-up the service you are talking to, those in-flight requests will not be able to take advantage of the new capacity. If those requests were instead sitting in a message queue, when new processing power came online they can be handled right away. Async has some tradeoffs though. It is generally more difficult to reason about. You often need to handle scenarios you do not in sync (like retransmits, or duplicate messages), and will generally not have the same guarantees around ordering.

@@DevOpsToolkit Yes, but you would still have to wait for the response even in an async architecture; it would just not be the responsibility of App1 but of a different consumer somewhere down the line. The fact that you need the response to continue does not disappear because you change protocols. Don't get me wrong: I love async for fire and forget scenarios, but saying sync is not performant by taking a RPC call as an example (what it is especially good at) is a bit weird. Now, if what you are saying is that you need more tools to make sync work for RPC at scale, I agree. You would need both clients and servers to be able to handle requests asynchronously, you would need to add a load balancer, retry mechanisms etc... all of which come out of the box with async but nothing can be more performant (i.e. provide a faster response) than sync for RPC in my opinion.

@@BPTScalpel You're right. I made a mistake by not explaining it well. A direct sync reqest/response is performant.

It all depends on how you configure the broker. Also, more often than not, they don't send messages but allow other processes to subscribe to messages of certain type/subject.

@@DevOpsToolkit Thank you so much for answering and making it easy to understand this!

Tracing tools like Jaeger can help with that.

You mean that you are trying to store data that is not uniquely identifiable so you might end up storing more than one copy?