Thank you!

How fast do you need it to work? Orchestration is generally for workflows, not super-fast responses. If you need real-time answers, and are fine with some dropped requests, a simpler solution is often better.

Yeah, there were plenty of posts on this. TL;DR: If the underlying DB stores it as 128 bits, there really is no noticeable harm in storing the UUID directly.

@@dimakorolev ok, thanks!

Yeah, I'm trying hard to make it more conversational! Happens a lot off-the-record, but the ones we record appear to mostly be me speaking still 😞

@@dimakorolev thanks for lot for posting this content. I am preparing for my system design interviews at Google and Microsoft. I am never a fan of this kind of interview. Your videos are explaining the thought process behind it. I read klepmann's book and, also covered the fundamentals of distributed computing. Your videos are where I see everything tied together. Design auth , exactly once are all wonderful topics. I am going to watch all the content here. I am moving my interview by a week to cover all the videos.

tinyurl.com/sdm-slack-invite

tinyurl.com/sdm-slack-invite tinyurl.com/sdm-discord-invite Our Slack is by far more popular, but I can accept the possibility of this changing in the future.

I wish there were enough hours in the day. We're trying though, thank you for your encouragement!

does tinyurl.com/sdm-slack-invite work?

Also, there's tinyurl.com/sdm-discord-invite now!

Heh, technologically I do believe Web3 is in good shape. Whether the regulatory frameworks or the free-spirited individuals prevail in the longer run remains to be seen.

Thank you Davon! Recording shorter episodes is on my TODO list all the time, but looks like it does work better when I expand on the ideas in depth. Hope we can get the best of both worlds one day!

Thank you. This topic is something I'm pretty knowledgeable in, and there was quite some time invested into preparations. Glad to hear it's worth it for you!

Much appreciated, stay tuned for more!

tinyurl.com/sdm-slack-invite

@@dimakorolev Спасибо!

Будем работать над улучшением качества ;)

In reality, even though actors and coroutines don't technically contradict one another, the high-level design decision is generally one or the other. Either you bet on being lock-free, and emphasize each actor having its own state ("you don't communicate via shared memory, you communicate to share memory"), or you bet on high performance via high concurrency and handle possible (and tricky!) multithreading issues yourself. That's the theory. In practice, one is 99% likely to be using coroutines when they are using actors. The coroutines themselves would just be hidden deep enough in the actor framework they use, be it something external or something small and home-brewed. Keep up with great questions, and thank you!

@@dimakorolev thank you - that makes sense. Great video as always!

That's actually a big question, largely because most pages these days are served by a CDN, so the very domain name would resolve to a different IP address and the request would to different servers accessed in different parts of the world when queries from different places. For the simple case, it's easy: resolve the DNS name from different datacenters, if they return the same IP, geo-locate it and/or try crawling from different places and measure the throughput/latency yourself. For CDN-served content, I'm on expert, but would imagine there is a way to request the CDN to return the best location to query it from (I would want it to be a primary location, so that it's updated faster, and my crawler catches fresh pages sooner). On the other hand, we may just ignore this part altogether and rely on our own algorithm that tries crawling pages from different datacenters and gives preference to the one that responds with content faster. Last but not least: the server may return different content for crawl requests from different places. This is also something to be factored into the crawler algorithm.