[John23832]

Sites like leetcode overindexes on the rote abilities that you can stamp out. Actually building something is exploring in a creative way which builds a deeper understanding.

If you want to be "optimal, neat, or best practiced" read a book, and get stuck in tutorial hell. If you actually want to learn how to do something, literally go do it. Nobody has ever built anything of value (whether that is financial, intellectual, or emotional) by leetcoding.

[ActionHank]

Any suggestions for books to read?

[mannyv]

What you should read or start with are the designs for Cassandra, Kafka, Foundation DB, etc.

The problems they're trying to solve are related to really large distributed systems that fail a lot, and their design decisions are basically a "this is how we worked around that problem."

You can also look for the LISA archives (https://www.usenix.org/publications/loginonline/thirty-five-...). System administrators were the first people that had to deal with large distributed systems at scale, and university system administrators led the charge.

You might want to hunt down the comp.sys.admin archives (I can't remember the newsgroup anymore).

Most of the ideas and issues behind distributed computing are obvious if you think about it. Many of the actual implementation and mitigation of those are not obvious, though.

And there's also the client side of distributed computing, which I don't think is discussed as much.

As an example, exponential backoff is one of the go-to techniques for clients when the servers are under load. Unfortunately that doesn't really work IRL, because instead of spreading the load you get waves of load coming back over and over. Likewise on the server side you have problems with peak load.

[John23832]

The only one I would really suggest is Designing Data Intensive Applications. But it is very DB centric.

https://www.amazon.com/Designing-Data-Intensive-Applications...