TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Learning to Build Distributed Systems

389 pointsby SirOibafalmost 6 years ago

12 comments

i0exceptionalmost 6 years ago
Being on-call/carrying the pager for a complex and unstable distributed system is a great way to understand how to build a good one. Building a distributed system isn't hard per-se. It's almost always the non-determinism and the associated difficulty in debugging errors that's a problem.
评论 #20250450 未加载
评论 #20250542 未加载
评论 #20251690 未加载
评论 #20252322 未加载
评论 #20251162 未加载
评论 #20252368 未加载
评论 #20250325 未加载
wippleralmost 6 years ago
I found &quot;Designing Data-Intensive Application&quot; book to be really helpful introduction to learning more interesting details about distributed systems. The book provides a gentle introduction to build intuition around these systems and contains a plethora of links to go further down the rabbit hole.<p><a href="https:&#x2F;&#x2F;dataintensive.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dataintensive.net&#x2F;</a>
评论 #20251617 未加载
healsjnr1almost 6 years ago
Aside from theoretic advice, one of the key things I&#x27;ve found euros best is _not_ to set out to build a big complex system.<p>Solve small problems that deliver value in distributed way and then iterate and expand. Doing this focuses engineering on the real problems that need to be solved at the scale you are working at. This delivers real understanding of what is going on, both theoretically and specially within your domain.<p>The retort to this is often you&#x27;ll never get to scale, or that your architecture will be incoherent. Basically you need to see the whole picture and build towards it.<p>The caveat is that solving small problems doesn&#x27;t mean &#x27;do something quickly or hacky&#x27;. If you do, sure you&#x27;ll end up with an incoherent mess.<p>If you maintain good engineering practices, and focus them on real problems, my experience is you will scale your platform. These practices will keep focused on solving real problems properly, and doing so will give you an understanding of what the next problem is going to be.
评论 #20252507 未加载
gregorygocalmost 6 years ago
I was being bootstrapped into the new project (pretty big distributed system) for 6 months since I went on call. But then my debugging skills skyrocketed, and I know it’s a little inconvenient to wake up at 5 am because of pager duty sad trombone sound, but I know it’s an investment on my part to become a better distributed systems engineer.
ignoramousalmost 6 years ago
Disclaimer: ex-AWS. Not for reproduction.<p>&gt; There are a lot of distributed systems books I love, but I haven&#x27;t found an accessible introduction I particularly like yet.<p>I&#x27;d highly recommend Martin Kleppmann&#x27;s Desgining Data Intensive Applications [0] as an introductory book on distributed systems.<p>&gt; Here&#x27;s Jaso Sorenson describing the design of DynamoDB<p>For the uninitiated, Jaso played a key role in S3&#x27;s evolution and was one of S3&#x27;s founding engineers along with the then CTO and now Distinguished Eng, Alan Vermeulen (who&#x27;s probably Jeff Dean of Amazon), who btw is an expert speaker. Such a shame folks outside of Amazon don&#x27;t get to see his numerous talks. Absolute legends.<p>&gt; Colm MacCarthaigh talking about some principles for building control planes.<p>Jaso also built &quot;one of the most complex distributed systems ever built at AWS&quot;, what then later formed inspiration for AWS HyperPlane and the NetworkLoadBalancer by a team led by Colm, who inturn, was a founding eng with Route53 (first-ever 100% uptime public service at AWS?), VPC, and CloudFront among other very fancy security things.<p>&gt; I&#x27;ve (Marc Brooker) been doing this stuff for 15 years in one way or another, and still feel like I&#x27;m scratching the surface.<p>Well, he&#x27;s being humble here. Marc&#x27;s internal wiki pages on various designs he&#x27;s come up with over the years for AWS are absolute gold mines, in that they explain his thought process, his experimentation, and his research with existing publications. Along with Colm (and a few others), he&#x27;s is a prolific speaker internally at AWS with some of his talks ranked in the top 10 consistently. His recent contributions with EC2&#x2F;EBS and Lambda mean he&#x27;s worked with the largest and most complicated distributed systems there ever has been at AWS (imo, of course).<p>There are others like Eric Brandwine (Security), James Hamilton (Data Centers), Peter Vosshall (Silk, EC2, and Architecture), Becky Weiss (VPC and Lambda), David Yancek (IoT, NoSQL), Andrew Certain (DB), Tim Rath (DB), Stefano Stefani (DB, Warehouse, AI), Brad M (S3), Nafea B (Hardware), MSW (EC2&#x2F;OS), A Ligouri (EC2&#x2F;OS), Hall Cary (Builder Tools), Marvin T (Kinesis) et al who don&#x27;t get a mention in the blog post but have been every bit gigantic in their contributions at AWS since forever. The recent recruits at the top rungs of eng at AWS have considerable pedigree coming in, as well. Exciting times, for sure.<p>I wish they&#x27;d release those internal videos (and CoEs) on a case-to-case basis to public. That&#x27;d go a long way in contributing to the distributed systems literature... apart from resuming to write blogs and papers abt their systems [1] like the NetEng&#x2F;Route53 team once did.<p>[0] <a href="https:&#x2F;&#x2F;dataintensive.net" rel="nofollow">https:&#x2F;&#x2F;dataintensive.net</a><p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19290069" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19290069</a><p>(Opinions my own. Facts presented may not be accurate. Zero intention to cause hurt and anguish.)
评论 #20253237 未加载
评论 #20251716 未加载
redact207almost 6 years ago
I&#x27;ve been building distributed systems, big ones, across banking and gaming for many years now.<p>The only thing that makes it successful is correct data modeling and application boundaries. Domain driven design is a great way to start and cqrs a good next step.<p>Trying to make a poorly built application distributed is like trying to make a poorly built class testable. You can kind of do it, but it&#x27;s a lot of extra messing around and it never really works properly.
gregoryexealmost 6 years ago
&quot;If you can, carry a pager&quot;<p>Why a pager? I wasn&#x27;t even sure that they still made them.
评论 #20251353 未加载
评论 #20252073 未加载
tabtabalmost 6 years ago
Keep Conway&#x27;s Law in mind. You usually can&#x27;t solve organizational problems with technology alone. If your staffing structure is not also &quot;distributed&quot;, then making systems that are could hurt you.
shinryuualmost 6 years ago
Does anyone have a good recommendation for a mooc on distributed systems?
评论 #20251815 未加载
maxtollenaaralmost 6 years ago
Marc brooker is a legend
anth_anmalmost 6 years ago
Another article about how hard it is doesn&#x27;t mention the hardest part of all.<p>Getting to a place where you will ever get a chance to work on this stuff.<p>I tried joining a team working on it. Figured I wouldn&#x27;t get to do a lot, but it was a foot in the door sort of situation.<p>By the time I quit I had managed 7 months without doing a thing, and 3 more where I wasn&#x27;t even trying anymore.<p>Meanwhile the guys who built the thing all got pulled to work on the next big thing. Maybe they were just amazing engineers.<p>Maybe getting hired out of college and putting right onto a massive distributed systems project is the only fucking way to ever get your foot in the door.<p>I&#x27;m not gonna let this article ruin my day. It&#x27;s pointless. I can think about how colossally fucked my career is on monday.
评论 #20253229 未加载
unnouinceputalmost 6 years ago
&quot;List of articles to read to learn about distributed systems&quot; - there I fixed the title for you
评论 #20251452 未加载