Is Young Bloods a common term for beginner / newbie ?
yup
Notes on Distributed Systems for Young Bloods
41–50 of 57 posts
Re: Notes on Distributed Systems for Young Bloods
#42One that is not mentioned here but that I like as a general principle is that you cannot have exactly once delivery. At most once or at least once are both possible, but you have to pick your failure poison and architect for it.
Can’t stress this enough. Thank you for mentioning it!! In my career I’ve encountered many engineers unfamiliar with this concept when designing a distributed system.
> I’ve encountered many engineers unfamiliar
tbf, Distributed Systems aren't exactly easy nor common, and each of us either learn from others, or learn it the hard way.
For example, and I don't mean to put anyone on the spot, Cloudflare blogged they'd hit an impossibly novel Byzantine failure, when it turned out to be something that was "common knowledge": https://blog.cloudflare.com/a-byzantine-failure-in-the-real-... / https://archive.md/LK8FI
Re: Notes on Distributed Systems for Young Bloods
#43Is Young Bloods a common term for beginner / newbie ?
https://www.merriam-webster.com/dictionary/youngblood
young· blood
1: a young inexperienced person
especially : one who is newly prominent in a field of endeavor
2: a young African American male
The first known use of youngblood was in 1602
Re: Notes on Distributed Systems for Young Bloods
#44Re: Notes on Distributed Systems for Young Bloods
#45> If you can fit your problem in memory, it’s probably trivial. A corollary: "in-memory is much bigger than you probably think it is." I thought I knew what a large amount of RAM was, and then all the major clouds started offering 12TB VMs for SAP HANA. edit: this seems like it's touched on very briefly with "Computers can do more than you think they can." but even that only talks about 24GB machines (admittedly in 2…
Even comparatively senior engineers make this mistake relatively often. If you're a SaaS dealing with at most 100GB of analytical data per customer, (eventually, sharded) postgres is all you need.
Re: Notes on Distributed Systems for Young Bloods
#46> Distributed systems are different because they fail often
The key here is not just the rate of failure, but the rate of failure in a system of multiple nodes.
And - "distributed systems problems" don't only arise with several servers connected by a network. Any set of nodes with relations between them - files on disk linked logically, buffers on different IO devices - these are also going to face similar problems.
Re: Notes on Distributed Systems for Young Bloods
#47Excellent list; I like the pragmatic and down-to-earth explanations. No buzzwords, no "microservices" (: I'd say that a good amount of this advice also applies to one-box systems. There can be lots of kinda/sorta distributed sub-components to consider — could be IPC between programs, or even coordination amongst threads in one process. Even the notion of unified memory on one box is a bit of a lie, but at least the h…
The neighboring universe, so tantalizingly close, where AMD gave us different memory spaces for each chiplet, is something I think about often. Imagine, we could all be writing all our code as beautiful distributed memory MPI programs. No more false sharing, we all get to think hard and explicitly about our communication patterns.
Re: Notes on Distributed Systems for Young Bloods
#48Re: Notes on Distributed Systems for Young Bloods
#49One that is not mentioned here but that I like as a general principle is that you cannot have exactly once delivery. At most once or at least once are both possible, but you have to pick your failure poison and architect for it.
It's impossible to have at least once delivery in an environment with an arbitrary level of network failure.
Sure you can: keep sending one message per second until you receive a response from the recipient saying "OKAY I HEARD YOU NOW SHUT UP!"
Re: Notes on Distributed Systems for Young Bloods
#50One that is not mentioned here but that I like as a general principle is that you cannot have exactly once delivery. At most once or at least once are both possible, but you have to pick your failure poison and architect for it.
It's impossible to have at least once delivery in an environment with an arbitrary level of network failure.
You can have at-least-once-or-fail though. Just send a message and require an ack. If the ack doesn’t come after a timeout, try n more times, then report an error, crash, or whatever.