Fantastic video! I especially liked you mentioning anti patterns. They helped a lot with understanding the concepts

@SoftwareDeveloperDiaries

Ай бұрын

Glad you enjoyed it!

Thank you for this video. I really enjoyed it!

This is so useful! Needed done help untangling spaghetti and now I've got a deeper understanding of these tools

@SoftwareDeveloperDiaries

Ай бұрын

Perfect!

Shared db shouldn't be called an anti-pattern. Becasue if you have a split payments and users dbs, you'll still have some dependencies between them, and you're complicating your life drastically by rolling out a multi-db transaction, it's super error prone. So multi-db schema hard to get right and hard to maintain.Deadlocks doesn't seem to be a relevant argument, because if you're updating tables that aren't related there cannot be a deadlock. And if you're updating user and a payment simultaneously, you can run into a deadlock condition either with a shared db, or during your multi-db transaction. 3:00 "If you're trying to scale in the future" - valid point, but "in the future" is the key here. If you'll have to scale it in the future, you'll be dealing with more problems of multi-db transactions in the future, rather than from the beginning. And watching further only assured how error-prone distributed transactions are. "1 phase: we begin and do inserts, 2 phase we do the commit" - no, this is wrong, it will be screwed up if your "commit" query fails in the second phase, this is not what 2 phase is. And this is the exact reason why everybody should avoid designing multi-db microservices at all costs without necessity, and do a thorough research if there is a necessity. "And a second pattern is Saga, but rollback here is too complicated for explanation, so let's move further, but remember that the simple way is an anti-pattern"

great video!

Learned a lot and it helped me relax on a Friday night. Thanks man

This was well explained

Bro can you make mern stack project with DDD clean architecture Cqrs event sourcing

I have one doubt also when to use kafka and when rabbitmq i read some where kafka is log base and rabbit mq is in memory..????

@LtdJorge

Ай бұрын

Kafka is an append log, basically a queue. It has the capability of persisting to disk every message it takes at the same time that it gives it via network to a subscriber to the topic. RabbitMQ is a message broker. It's similar, but instead of being mainly one message goes in and it's delivered to one consumer, you can deliver to many subscribers, set routing based on the message content, configure persistence or no persistence, etc. If you need an extremely fast message buffer, use Kafka. If you need a message broker (more suitable for event-driven architecture), use RabbitMQ (or NATS, or many others).

Superb Video. I would like to see practical samples of what we discussed here

@SoftwareDeveloperDiaries

Ай бұрын

Coming soon!

Can we say that CQRS is similar to setting up read replica. Where there ia a master and multiple read slaves

I'm so early that higher resolution is just not available yet.

@oguznsari

Ай бұрын

same for me 😅

@SoftwareDeveloperDiaries

Ай бұрын

Hahaha should be sharper now

hello sir this is best explanation video . i was send connection request linkdin please accept

Sir do you earn 100k euros a year as a software engineer? Plz reply. Thanks a lot.

@SoftwareDeveloperDiaries

Ай бұрын

No, I don't 🙂

@gourabsarker9552

Ай бұрын

@@SoftwareDeveloperDiaries which country do you live in?

@Aleks-fp1kq

Ай бұрын

I do, even more than that 😂

@LtdJorge

Ай бұрын

​@@Aleks-fp1kqok

Better architecture or you mean a lot money to spend

@Dom-zy1qy

Ай бұрын

You know, you're kind of right and it makes me sad. Cloud architecture is actually pretty fun, but you're bottle necked by the amount you have to spend. (Like most things in life lol) Although there is some fun to be had in trying to squeeze out as much as possible from free tiers.

great content