Partly. You can learn the vocabulary and the standard patterns of system design without writing code: what a load balancer does, why queues exist, what the CAP theorem says. You can’t learn to make design decisions you can rely on that way. Every box on a system design diagram is a running program with limited memory, CPU and connections, and every arrow is a network call that can be slow, arrive twice or fail halfway. Until you’ve built and debugged software yourself, those boxes and arrows stay abstract.<\/p>\n
Here’s what you can learn from the outside, what you’ll miss, and the smallest amount of coding that closes the gap.<\/p>\n
For some jobs this is enough. A solution architect who coordinates vendors, a business analyst or a product manager mostly needs to know what each piece does and what it costs, and can rely on engineers for the rest.<\/p>\n
Writing code teaches you how memory, disks and networks actually behave. A network round trip inside a data center takes thousands of times longer than reading from memory. A missing database index turns a quick lookup into a scan of every row. A database accepts only so many connections at once.<\/p>\n
Take connection pools. Each app server keeps a pool of open database connections. Twenty servers with twenty connections each need 400 connections, and PostgreSQL allows 100 by default. On a diagram, “add more app servers” looks like the fix for more traffic. On the real system, the database starts refusing connections and requests fail. People who’ve watched a pool run dry under load spot this at once. People who’ve only drawn diagrams usually don’t.<\/p>\n
Distributed systems rarely fail cleanly. A message arrives twice, or after a newer one. A request times out after the work was already done. Two users grab the last seat at the same moment. You don’t feel how hard event-driven designs are until you’ve chased bugs like these (we wrote about one kind in why event-driven architectures cause race conditions<\/a>).<\/p>\n Here’s the most common one in a few lines of Python. A payment goes through, but the response is lost on the way back, so the client retries:<\/p>\n Output:<\/p>\n Without a key, the customer paid twice. An idempotency key is an ID the client sends with each request so the server can recognize a repeat and return the first result instead of doing the work again. Stripe’s API accepts one for exactly this reason. On a diagram, both versions are the same arrow.<\/p>\n A design also has to be buildable, testable and debuggable by the people who will work on it. If you’ve never spent days following one request through the logs of five services, or untangling two modules that depend on each other, you won’t notice when a design adds that kind of work for every engineer on the team.<\/p>\n Engineers are wary of architects who hand down designs without knowing what implementing them involves. If you can’t talk about API contracts, data formats, timeouts and error handling in terms they recognize, they’ll quietly build around your design.<\/p>\n You don’t need years of low-level programming. You need to have built one small system and watched it break.<\/p>\n A few weekends of this changes how you read every system design diagram afterwards.<\/p>\n Interviewers use follow-up questions to find out whether you’ve built things: “What happens if this call times out?”, “What if the message is delivered twice?”, “How many connections will the database need?” Answering them well takes the implementation knowledge above.<\/p>\n AlgoCademy’s system design lessons<\/a> are built around these questions, with lessons on timeouts and retries, idempotency keys, concurrency and locks, and caches that go wrong. The Foundations lessons are free, including latency numbers<\/a> and an eight-step framework for the interview<\/a>. For a broader study plan, see how to learn system design and architecture<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" You can learn system design’s vocabulary without code, but not how to make designs that hold up. Where the line is, and the least coding that closes it.<\/p>\n","protected":false},"author":1,"featured_media":10127,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-10126","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-problem-solving"],"_links":{"self":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts\/10126"}],"collection":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/comments?post=10126"}],"version-history":[{"count":0,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts\/10126\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/media\/10127"}],"wp:attachment":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/media?parent=10126"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/categories?post=10126"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/tags?post=10126"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}charges = [] # what the payment provider has recorded\nseen = {} # idempotency key -> the result of the first request with it\n\n\ndef charge(amount, key=None, lose_response=False):\n if key is not None and key in seen:\n return seen[key] # a repeat: return the first result, charge nothing\n charges.append(amount)\n result = {\"charged\": amount, \"id\": len(charges)}\n if key is not None:\n seen[key] = result\n if lose_response:\n raise TimeoutError(\"the charge went through, but the response was lost\")\n return result\n\n\ndef pay(amount, key=None):\n try:\n return charge(amount, key, lose_response=True)\n except TimeoutError:\n return charge(amount, key) # the client can't tell what happened, so it retries\n\n\npay(50)\nprint(\"without a key:\", charges)\n\ncharges.clear()\npay(50, key=\"order-1042\")\nprint(\"with a key: \", charges)\n<\/code><\/pre>\nwithout a key: [50, 50]\nwith a key: [50]\n<\/code><\/pre>\nWhat makes a design easy to build and maintain<\/h3>\n
The trust of the engineers who build it<\/h3>\n
Where the line is<\/h2>\n
\n\n
\n \nWithout code, you can<\/th>\n With coding experience, you can also<\/th>\n<\/tr>\n<\/thead>\n \n Explain what a cache is for<\/td>\n Predict when it serves stale data, or when many requests miss at once and all hit the database<\/td>\n<\/tr>\n \n Draw a queue between two services<\/td>\n Handle messages that arrive twice or out of order<\/td>\n<\/tr>\n \n Say “add more app servers”<\/td>\n Check whether the database can take the extra connections<\/td>\n<\/tr>\n \n Name the CAP trade-off<\/td>\n Decide what your app shows a user while a replica is behind<\/td>\n<\/tr>\n \n Pick managed services<\/td>\n Predict what their limits and outages will do to your system<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The smallest amount of coding that closes the gap<\/h2>\n
\n
tc netem<\/code> does this). Retry requests and look for duplicates. Drop an index and watch the response times.<\/li>\nIf you’re preparing for system design interviews<\/h2>\n