Design more decoupled services with one weird trick - Udi Dahan - NDC Oslo 2024

preview_player
Показать описание
This talk was recorded at NDC Oslo in Oslo, Norway. #ndcoslo #ndcconferences #developer #softwaredeveloper

Attend the next NDC conference near you:

Subscribe to our YouTube channel and learn every day:
/ @NDC

Follow our Social Media!

#microservices #ddd #architecture #api

Developers have been trying to build more decoupled systems for years, but the same challenge keeps popping up: how much data do you pass between things, whether via an API or through events?

Lots of parameters means lots of coupling. Passing over just an identifier means the receiver needs to look up the data it needs, essentially sweeping that coupling under the rug and pretending it isn't there anymore.

Join Udi to see the "one weird trick" that rotates the design space enabling services to be so much more decoupled, each encapsulating their data that much more completely.

You won't believe what happens next!
Рекомендации по теме
Комментарии
Автор

Udi is a fantastic speaker and this is a great talk and it has been featured in the last issue of Tech Talks Weekly newsletter 🎉
Congrats!

TechTalksWeekly
Автор

Listening to Udi is always both a pleasure and a great education. To explain a complex thing in simple words as a coherent story requires lots of knowledge and experience. Thanks for sharing. Like always, it was legen… wait for it… dary. Legendary 😀

penaplaster
Автор

Great talk for a great speaker... I can rallly! recoment his 5 days class.. Absolutly worth the time and money

t
Автор

Spoiler: the trick is to generate a client side ID for your entities.

With all due respect to Udi, I'm kinda disappointed by this talk. I expected something about managing coupling in complex systems, but this turned out to be about a specific solution to a specific problem.

FenelZ
Автор

Calling separate service APIs from micro-frontends carries risk of compromising order integrity. If any of the network calls fails, it will leave the backend order in an inconsistent state. For any revenue generating system like two examples mentioned, it is not a risk worth taking, IMHO. Do the trade-off analysis before implementing the de-coupling at UI layer. Tx

NitinGaur-bl
Автор

Important note, that if you're "packaging" all the data into 1 request, which will be split and sent to different services later on, then your business might lose important metrics, for example, when order is placed, but shipping (or anything else) information was not provided. Cause order is placed as a whole or not at all. If I were a business, I'd want to know why and where is the problem.

You can still achieve somewhat the same result with stream processing (aggregation, ksql, whatever) and collect important metrics.

Or am I missing something?

Fikusiklol
Автор

the shape of data is just as much a constraint as the behavior

vbachris
Автор

This is hilarious. Spoiler the trick is in his name!

minor
Автор

My user clicks on a button in a screen. Please tell me how Pub/Sub could work with it without transforming an interaction based flow into a subscription based, without "increasing complexity".

panosdotnet
Автор

Have you really decoupled your system if every part of your system must use the same unique ID for a given entity? Sure, if you remove your FKs and move data to a different database, you won't find an arrow in your DB diagram linking two entities together, but there is still logical coupling between them. Now you have introduced more complexity to handle your business logic. Is it worth it? Maybe, depending on the complexity of your product and organization. Building any sufficiently complex distributed system is hard, so do it only when there are clear advantages present in your concrete situation.

Автор

The sales component is totally decoupled. An item is an item and it has a price.

Until you start selling services, whose price may be based on a rate and a duration, and the duration may not be known up front. Or the rate may change over time.

In the real world business rules are not as decoupled as this presentation assumes.

allmhuran
Автор

"you cannot show one price and charge another price". What planet is he from ? :D

sarunas
Автор

Please dont waste your time like me. his trick is that if you want to manage decoupled data at different parts, create corelating ID upfront before record is created and use it for parallel functions for coupling where needed. This is first NDC Conference video i found so bad and got tricked into watching it.

hnb
Автор

Why the "clickbait" title for a tech talk? It's not even funny. People interested in these topics need to invest their time wisely.

eriks
Автор

resume-driben development, that's how average works, they come in packs.

flashflexpro