Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What is best way to do hands-on practice for system design?
222 points by maheshs on July 16, 2022 | hide | past | favorite | 93 comments
I have build many small size web apps.

I lack experience in designing medium to large application. I tried to read system design content but not able to gain confidence.

How can I do the hands-on practice of system design concepts. Please your tips, resources, plan etc.




You get hands on experience at a place

1. That has a functioning app

AND

2. Business is growing rapidly bringing more customers than the system can handle.

In other words you learn on the job by getting your hands burnt. I got lucky to have joined such a startup. Learnt a lot, from fixing DB queries, designing asynchronous order processor, using CDN etc. I worked on scaling up the full stack including stuff like connection pools.

So your best bet is to join such a startup. You will learn a lot by handling real user traffic. And also scaling isn’t homogeneous. For example, you make different trade offs scaling a search application Vs scaling a payment processor. So business use case and business domain does matter.


I've got my hands burning over the last 12 years in 4-5 places like that.

From web & app, frontend, to backend, databases and server management.

Yet I still find it hard to grasp good system design.

At best I prefer things to be as simple and clear as possible, that's about all I'm certain off.

Most systems are already so established if they get going, you are mostly patching. Once you start patching all effeciency goes out the window, especially if those who build v1 are gone. Hard, and most often a bad idea, to overhaul a system to something more stable & efficient.

Now that I think of it, probably my biggest learnings are what not to do, not what to do.


> you learn on the job by getting your hands burnt.

That's how it works in new fields where there's no good theorical foundations yet. I think OP is asking if we already know how to avoid getting hands burnt in the first place, as in many other fields of engineering where you don't just learn on the job and get yourself burnt a few times.


This is why I think "software engineering" is more of a creative field than a "hard engineering" one. More akin to painting or singing. You need practice in order to improve solving problems in the real-world, you can't just read up on it and become better than people who've actually implemented useful things in real scenarios.


I think that in the area of system reliability, specifically, there's quite a lot of theory that's useful and often ignored by practitioners, though. Saying you need to learn everything on the job is akin to cowboy system design. There's a lot of collective knowledge you should absolutely use when designing large systems, and ignoring that body of knowledge by assuming the only way is learning on the job is a mistake.

I believe not long ago, medicine was like that. Clearly, things can, and should, become more standardized and that will not in any way encumber the creativity that is also a big part of our field.


This only works if you work someplace that has complicated problems and/or architecture astronauts who like to overcomplicate everything. Every small, mid and even most large-scale tech shops are able to execute on goals using off the shelf software. How do we scale payments at my org? We pay Stripe. How do we scale search? We pay Alogolia. How do we scale our public facing web sites? We pay Amazon. I've been in architects/director roles at multiple orgs for over ten years and everything they ask at FAANG system design interviews is still stuff I've only read about.


To add something further to this excellent comment:

Join a start up with a legacy code base, e.g. dodgy old PHP that they’re pulling out into modern domain services.

Within a year you’ll be able to analyse performance and scalability issues and refactor them in your sleep.


If you want to build your skills, sure go ahead.

But working at a company like this is not a good way to build your wealth. You're far better off working at a big tech company that has awesome benefits or a fresh startup. Startups that have been around long enough to have a legacy code base aren't a place to become wealthy.


> But working at a company like this is not a good way to build your wealth

Common software engineering mistake: focusing on solving the wrong problem.

OP wants to practice hand-on system design. OP never writes about "building wealth" and doesn't even mention money anywhere. So where do you get that this is about building wealth?


Not everyone aims to be wealthy. Most companies do pay a decent salary (specially in europe) with good work life balance. High paying jobs often correlates with high stakes which means potentially higher level of stress.


I don’t think the high paying job = big stress correlation is as strong as you might think. Sure a few places are known for bad work life balance but (especially if you are employed in Europe) I would guess many big companies offer better WLB than startups - in fact, I’m sure the pace might be “too slow” compared to smaller companies in many teams.

There are plenty of valid reasons to not want to work at big tech co’s, but if you’re discounting it for expected stress level alone I’d do a bit more research as I don’t think it’s as true as you think. Obviously read reviews of Glassdoor/Blind to get a sense of the company you’re applying to…


I think the comment meant "wealth" in the pg sense https://www.paulgraham.com/wealth.html


Not necessarily, the biggest most rapidly growing project I was with only taught me anti-patterns, but I guess that's something you need to learn too ...


You learn large scale system design via real world application, being in the room when it happens, and from closely working with folks who are already practicing it. This kind of work is sometimes as much art as it is science, highly specific to the situation at hand and requirements of the system to be designed.

It absolutely bothers me that the resources out there are few and far between. It is hard to change that. I encountered occasionally resistance in organizations to share more openly the process, e.g. I suggested video taping it and uploading the video as a start. Naturally, plenty of confidential information can be disclosed in such design sessions, so enthusiasm about sharing recordings is rather low, even when everyone in the room agreed to be taped in the first place (which in itself is almost impossible).

I am bothered by engineering topics that have this „tribalism“ way of education. In networking one of these areas is BGP. No one lets you near Border Routing until you can do it perfectly, because of it potentially catastrophic impact (Pepperidge Farms remembers Pakistan Telecom hijacking YouTube!). When I tried to solve that one I ended up spinning up a whole ISP which’s sole purpose is to play with and break BGP. [1]

For system design I haven’t found a solution yet, ideas welcome. In the meantime, all you can do is read the little that is available (e.g. [2]) and try to talk to as many practitioners as possible, asking them to share or simulate a session privately.

1: https://www.nonattached.net 2: https://cloud.google.com/blog/products/management-tools/sre-...


Note that system design interviews are often completely customized and adapt on the fly to the applicant's responses, so there's no way to do a "cracking the system design interview" the way you can with coding problems. When I give coding interviews I have one question that I give over and over again, learn the ins & outs of the questions and how candidates go wrong, and score based on whether the candidate can complete it, or how close they came to a valid solution if they couldn't. When I give system design interviews I pick a topic that's something that both the candidate & I have had experience with, start out with "How would you design X?", and see where the candidate goes, drawing on my background knowledge to prompt further about cases to consider and situations that might come up in the real-world implementation of the system. The candidate is generally driving the interview, because at the level where system design interviews become necessary, the candidate should know how to pro-actively anticipate problems.


> there's no way to do a "cracking the system design interview" the way you can with coding problems

I'd disagree:

- System Design Interview – An insider's guide: https://smile.amazon.com/gp/product/B08CMF2CQF

- System Design Interview Vol 2: https://smile.amazon.com/System-Design-Interview-Insiders-Gu...

- Designing Data-Intensive Applications: https://smile.amazon.com/gp/product/1449373321

- System Design Primer: https://github.com/donnemartin/system-design-primer

Especially: https://github.com/donnemartin/system-design-primer#how-to-a...


I'll second that the best way to get better is to be a practitioner.

Part of the reason that there's not more material on systems design is because the way we design systems is highly dependent on core systems that pre-exist a new system. You can learn all the things on paper about layer 8 vs layer 4 load balancing, how to build an effective distributed cache, how to building a decentralized rate limiter, etc but all of these things are highly dependent on what exists prior, and knowing how to work in non-greenfield components reflects an internal familiarity with them.

The other side to systems design is more analogous to producing a map of the world; eg: documenting systems as you work on them. When I was a new engineer, this is how I learned systems design. Every new system I encountered I would begin to model. This had the added benefit of teaching me UML and how to make designs that highlight the important parts.


What is layer 8?


Layer 8 load balancing is humans opening and closing browser tabs, I presume?


Layer 8 is generally called the Political Layer.


They must've meant Layer 7 / Application Layer. There is no Layer 8 in OSI model (unless they're talking about a different model)


I did mean Layer 7. I've been calling it Layer 8 for a long time now, lmao. Not sure how that got mixed up and made permanent.


There are alternative/extended models out there. Perhaps you ran into one of those?


Entirely possible; I've worked in the intersection of Software Engineer and Systems Engineer most of my career, so that leads me to think maybe I'm prioritizing some of the stuff I learn and that older things I've learned have degraded. I say that mainly because I learned the OSI model very early on in my career.


The only way I learned was the "main guy" flipped off management and walked out. You start learning real fast. "WTF IS PXE BOOT. Session vms aren't booting. Oh jesus, JEFF! HA_ERR_KEY_NOT_FOUND people can't login ". I couldn't learn anything otherwise due to nerves, PR gating and risks of catastrophic failure. But, when I was the only person left, let's roll it. PR approved!


Same thing happened to me! Entire career is based on a guy leaving, and being forced to use history commands to learn everything. lol.


Given the issues of BGP this is a great place to start an open education system!


Work through these books, then you start looking at any random app or system and can start from there:

- System Design Interview – An insider's guide: https://smile.amazon.com/gp/product/B08CMF2CQF

- System Design Interview Vol 2: https://smile.amazon.com/System-Design-Interview-Insiders-Gu...

- Designing Data-Intensive Applications: https://smile.amazon.com/gp/product/1449373321

- System Design Primer: https://github.com/donnemartin/system-design-primer

Especially: https://github.com/donnemartin/system-design-primer#how-to-a...

- The Architecture of Open Source Applications: http://aosabook.org/


Hmm. I think you might be getting at two different questions.

One: How do you get better at systems design? Build stuff -- lots of stuff. If you're interested in designing particular kinds of systems (say, planet-scale web services...), then get a job at a company that does that kind of thing.

Two: How do you get better at systems design interviews? That's much easier; you can just throw money at the problem. Use one of those paid mock-interviewing platforms where you can hire FAANG interviewers to anonymously interview you and give you feedback.

I just went through this interview prep and got the offers I wanted, so I can offer you a data point. It took me < 20 mock interviews (total cost of < $10K) to go from "I have no idea what I'm doing" to "I'm not worried about this part of the on-site interview loop." Admittedly, I have a decent bit of experience architecting systems at scale, so I was mostly using this approach to refresh my memory (heading back to a Big Tech job after several years of retirement) and get familiar with the interview format.

There are some common resources recommended for this sort of thing if you want to also make sure you've read the right content. The most helpful resources for me were the DDIA book [1] and the "Systems Design Interview" YouTube channel [2]. Both are great for breadth and getting exposure to a ton of different concepts -- after that, you can follow your nose (or the book's bibliography) to get depth on whatever you're most interested in.

Good luck with it! It's a deep and really fun rabbit hole. I suggest you find a particular type of system that you're really interested in; start pulling on that thread, and you'll inevitably find your way to all kinds of other fascinating systems-design topics as you go.

[1]: https://www.amazon.com/gp/product/1449373321/

[2]: https://www.youtube.com/c/SystemDesignInterview


> It took me < 20 mock interviews (total cost of < $10K)

That's a lot of money!


A pretty good ROI, if I had to guess?


Big plus-one for the Systems Design Interview channel. I learned a lot from watching those videos (repeatedly) when I was preparing.


Most people can't casually throw away 10k to get better at interviewing...

I'd say for us non-wealthy mortals, the best approach is to find another engineer who will conduct mocks for you. Short of that, maybe do one or two paid mocks to calibrate yourself, then practice on your own.

The sad fact is the "system design interview" is not really like actual system design at all. It's more about following a specific format that everyone expects and knowing the ideal solution up front.


First, it is very hard and there is no such thing as a set of perfect answers for every situation. So, relax and try to have fun while you learn - you might be right, you might be wrong and so is every other developer. L

Second, I think the best way to learn is to just work on a lot of systems. Sometimes your ideas will work out. Other times, you will wish you had become anything other than a software developer. Both states are equally helpful. It’s nice to write good software and have things work out. But you’ll learn a lot more from the projects you can only fix with ‘rm -rf’.

Third, try to get as wide a range of experience as possible. Be the lead designer on one project. And be extremely junior on another project. You’ll learn as much from implementing another person’s designs as you will learn from implementing you own.

And finally, have fun and be cool to everyone you work with. You will meet a lot of beautiful people and a lot of assholes. But if you love writing software, you’re part of the tribe. Make it positive and be cool to others. In twenty years, you won’t remember half of what you know now. But you will always remember developers who were kind to you when you were learning. Be one of those memorable developers…:)

Good luck. It’s a hard path but I know you can do it. You’ve proven it by starting off here.


I think practicing design is difficult because of one major issue: how will you know if you got it right? I think the only way is to actually implement the design, and learn what works and what doesn't (and, crucially, why).

It's essentially an apprenticeship: you work in teams and as you gain experience, you contribute progressively more and bigger ideas. One day, you get a job where the design is your responsibility.


Here are some tips which most of distributed systems follow :

1. Almost all distributed systems has a global load balancer sitting in front, which will distribute your traffic to nearest possible server.

2. Decide how do you want to make your DB replication to happen. Is it active/active, active/passive, P2P, etc ?

3. What do you choose between Consistency and Availability when Network Partition happen? Some databases like Cassandra are eventual consistent.

4. Any asynchronous tasks will need to use queuing service.

5. Any performant API will need to use Caching and CDN.


If by "large" you mean e.g. "under relatively high load" then you can simulate this load and learn to deal with it. Populate your databases with a lot of generated data. Use load testing tools. Add latency and faults to different parts of the system (you can even inject errors into storage system (e.g. device-mapper)). At some point you even can rent some big servers (e.g. cloud) to test you problems and ideas - the cost of learning can be very effective. Make some checklists and iterate over all the components:

  - what happens if this stuff fails (and how to test it, how to analyze it)
  - what attack surface that stuff has
  - how to scale if it receives x10 requests or becomes x10 bigger
  - how can you explain to a new coworker how it works, how all the decisions were made
It will rapidly give you the real understanding and practice. System design is about dealing with problems, making compromises. It is very hard to make an effective book (probably even impossible - it should probably be an interactive course at least) that will walk you through this process, not just throw a bunch of "patterns" at you (which is not useful and can infect you with the shallow cargo-culting that our whole industry is so full of).


I started a blog to explore this idea! I've built Pokemon Games to learn how to do things on a large scale. I've done Kubernetes, Redis Caching, nearly every flavor of Database (NoSQL, SQL, Graph, etc), and microservices, monoliths, you name it.

I'm going to be exploring how to go about it, how to massively over-engineer things for the sake of learning, as well as build minimalistic aspects of the games.

There will be `Main Quests` where we build a simple game, and `Side Quests` where we go off the wall and explore new tech.

I just started tonight! So it's definitely a WIP

https://mikercampbell.gitbook.io/gotta-code-them-all/


Hey, just created an account on HN just to say that I love the idea of your project. It rekindled my interest to learn Typescript and the premise of doing a smaller scale pokemon game just seems incredibly interesting and infinitely extendable. I blazed through the first few chapters and am desperate for more. I understand what the next steps should be, but I struggle to put them into non spaghetti code and would love to see your more modular approach on it. Really hope you keep going, this is so fun!


YES! This made my day! I've never screenshoted a HN comment before, but I had to keep this one and hold onto it. This really got me excited!

I'm currently working on the Caching (both in memory and with Redis as an option), how to generate Pokemon with random or specific values (like NPC teams need to have hard coded moves and levels, but you want random encounters to have random data) as well as the building the Overworld, with basic keyboard controls, collision detection, and beginning to have an ECS from scratch.

I'd love it if you would alpha test my next chapter? And please provide any feedback. Let me know where I'm too verbose, or if the code isn't clear or doesn't work for you!


Sounds awesome, would love to test it! Exciting topics coming up!

I added an email to my profile where you can contact me


Don't underestimate how much what you can learn building small apps will scale up to bigger ones.

The great thing about smaller projects is that you can take risks with them.

Build something small that uses a message queue. Then do a project that integrates with some web APIs. Then try building something that implements GraphQL. Then try integrating full text search.

When you get the chance to work on something bigger I guarantee you'll find this experience incredibly valuable. Larger systems tend to look a lot like smaller systems, but messier and more complicated because more people have been involved in helping grow them as their requirements have changed over time.


I know this isn't really what you asked, but I've administered hundreds of software engineer interviews, and there are two very common mistakes I see when it comes to system design:

1. Not clarifying the problem. The very first thing out of your mouth should be a series of questions that helps you define the requirements more clearly. Identify use cases. Try to understand the scale; questions that start with "how many" are good ones.

2. Not being concrete. For example, I had a design problem I'd give people that usually wound up with them sending lots and lots of messages in real-time from one system to another. But when pressed, very few people were able to describe the contents of those messages in any detail.

Just thought I'd pass that along in case it's helpful to you. And I'll second what a lot of other folks here are saying: the best way to learn this is to get experience.


> But when pressed, very few people were able to describe the contents of those messages in any detail.

Can you explain why this matters? It’s an architecture interview right? Not an API/Worker/Queue design exercise.

It’s not like I don’t expect someone to be eventually able to figure out the contents of the payload, I’d just not expect it to be at the forefront of their mind.


Emails with attachments vs plain text messages. Binary content. Compressed content. Size matters, especially at scale.


Ah, gotcha. We're still talking about 'what kind' of messages. Not, 'which fields', which is what I understood.


And I would add :

3. Not being specific about any technologies. Instead of using a "SQL Database" and a "cache", just say "PostgreSQL" and "Redis". It's an interview, if you're not specific, I will start thinking you don't have any experience with Redis or Postgres. If you really don't have any, I will find out anyway.


I would advise against it. Two reasons: - if the person interviewing you know the specific tech you picked, you give them an opening to control the interview. They can go anywhere they want and you would likely fall short unless you know the stack in&out

- when you pick specific technology, you also have to defend why this one specifically. For ex, why redis and not memcache or why only postgres and not redshift..

If you keep it at sql and no-sql, you can easily defend the answer and control the interview


As an interviewer I ding people who don’t understand the underlying capabilities. They often matter!

Like if the design depends on modifying two keys atomically, a transaction is required. Some KV stores have that ability, some don’t. Do you need the keys to be in the same shard now? What kind of persistence is required here?

Redis and Memcache are quite different where the rubber meets the road. Gotta know what you’re talking about, don’t handwave over the details.


I would also advise against it. At this level i would expect the more abstractive way of thinking. I don't see a reason to go so much in detail right now. Model > tools.


I interviewed someone who put an Amazon AWS product in every box on their design and was unable to explain how each would solve a particular problem except "Amazon product X solves this for us". No abstract thinking.

Strong no.


Great point. It's also hazardous if your interviewer does NOT know the specific tech you suggest. They may reject it with "Sounds suspicious, if that's any good why haven't I heard of it?"


All these differing opinions on this tells me interviews are a crapshoot subject to the interviewer's whims. If I got you for an interviewer I would need to be specific, for others who replied to this, I'd need to be generic. Hopefully the interviewer is helpful in this regards and indicates his preference, maybe by asking what cache would you use and why instead of silently docking me points.


I loathe secret requirements in interviews and am up-front and explicit about what I'm looking for. Even with that guardrail though, lots of folks don't answer the questions I'm asking. So I guess a more general piece of advice would be: listen to the interviewer, listen to the question, and answer the question that was asked.

(This is the same advice I give people when I'm coaching them for FAA oral exams, incidentally. People really have a hard time listening to a question and answering the actual question.)


From the inside, it can feel like there are actually too many rules. The interviewer is likely running a fairly narrow script. The interviewer probably believes they are being fair or generous when allowing minor deviations from their structure.

From the outside, it all feels random: unless you know the rules the interview is playing by, you can easily make a mistake. Each place has a different interview script and priorities.


I would think it doesn’t matter? Whether we use redis, memcached or anything else is irrelevant to the point, which is that you want ‘something’ to function as a cache.


I always recommend to read the classics (in addition to other excellent advice given here). Brooks, for sure, but also Vitruvius is _very_ relevant to designing large software systems. Then jump into the MIT System* ocean: system architecture (Crawley) gives you a framework for thinking about large and complex things, system safety (Leveson) a good framework for making things safe. Add some MIT product design and a ton of failing on your arse and you should be understanding you don’t still a thing in no time at all


You can pretend a small web app is a bigger one with a load testing tool like locusts[0]. If your design is good, it should be able to scale and handle more load. There are some more testing approaches listed here[1].

[0] https://locust.io/

[1] https://github.com/asatarin/testing-distributed-systems


Maybe on my experiens,I learn the system design by think about how to build the system or software in our life ,just like how to build a Uber or an Amazon. If you feel like it's a little hard to do, just try some simple things like a lift or a parking.

As you said ,you have a lot of small apps, mabey you could do something to link them together, and build a middle layer service for all the apps. In this progress, you should consider all the part of designing a distrubuted system, it could help you a lot, I guess.

Perhaps it's not the best way to improve the ablity for system design, it works a lot on me at least.


I think you can even take the smallest web app and make it into a more "real world" project. Take for example the classic counter demo. Try adding these features:

* i18n/l10n: Display labels in different language and correctly format the counter value for your user (1'000 vs 1.000). A user should be able to switch country

* Allow users to register and create their own counters

* Store the counter value in database hosted somewhere

* Store content stuff (title, labels, etc.) in a headless CMS and integrate with it.

* Set up build pipelines for your project

* ...and more :)


* Make this app multi tenant.

* Make this app highly available across geographies under heavy use.


Checkout highscalability.com, used to have lots of real word scalability issues and solutions back on the day.

If you want hands on experience, pick an open source app in the language you know and deploy it somewhere and load test till it breaks and see which part breaks first. It could be your load balancer can’t handle that many connections or you app server rubs out of memory or the db comes to a crawl. The more real world you can make load test queries the better.

At the very least you’ll get hands on experience.


Highscalability.com was great! I still follow their RSS feed but there's not a lot of new content nowadays. If someone knows a similar resource I'd love to hear about it!


The thing that helped me the most to design maintainable systems was the use of Clean Architecture. In particular, the [Cosmic Python Book](https://www.cosmicpython.com/), which offers practical examples on how to implement Clean Architecture in Python, and which design patterns are more useful to keep every layer independent.


I've had some limited experience with architecture katas[0] and they seem to do a decent job of exercising this skill. They're no replacement for experience, but at least they're _something_.

[0] https://nealford.com/katas/#:~:text=Architectural%20Katas%20....


Practical ideas off the top off my head:

Take a fast moving input data stream, and map it to some slower moving output streams.

Use a message queue, a web tier, a worker, and implement private and public caching internally in something like Redis. Implement HTTP caching.

Implement backups, failover, and recovery. Create runbooks and checklists.

Secure everything with MFA auth for admin-type users and design and implement lesser privileged user access.

Design and implement RBAC.

Add reporting, logging, fault-tolerance.

Make it platform agnostic and support multi-tenancy, i18n, and WCAG.

Support and test for HIPAA and GDPR compliance.

Document the whole thing.

Figure out how to write automated tests for all of these aspects.


I've done a couple. I'm working on one, right now.

I suspect that people would take issue with the exact implementations I use, but they tend to work fairly well, and have lasting power (I wrote an API for imaging devices in C that was still in use, 25 years later).

I wrote a backend system that is currently in use, worldwide, by thousands of people (I wrote it about twelve years ago), but has been taken over by a new team (I hardly have anything to do with it, anymore). I also wrote a few clients; most of which have been retired. The system I'm working on now, leverages it, and mixes it with another one I wrote (just a couple of years ago).

My way won't win Buzzword Bingo, but it WFM. YMMV.

I'm happy to share, but I've found that not everyone wants to do things the way I do, so I'll do so out of the public eye. I have a few generic things, here[0], that I've written, over the years, talking about some of my techniques.

[0] https://littlegreenviper.com/miscellany/


System design interviews have so far been a bit hit or miss for me. All the interviewers seem to be looking for something, but I’ll be damned if I know what it is.

I think I’m inclined to incrementally solve potential problems with the system (as introduced by the interviewer), where a lot of these interviews seem to want you to anticipate all issues.

So asking lots of questions about what they want is probably a first.


this describes my experience as well.


The best hands-on practice was when I had to build my own, nobody to tell me to cut corners and time to do things right. It's important to do it right to know how to do it wrong (most company will prevent you from doing things right because of time/budget constraints).

Ask yourself:

- What constitute a _good_ infrastructure?

- Something flexible/adaptable ?

- Something predictable ?

- Something resilient ?

- Something easy to monitor ?

- Something else ?

- How do you prioritize these, who gets to decide which one matters most...

Architecture is asking a lot of questions, inviting others who will benefit/use your work into the decision making process.

One thing that I learned that is still helpful to me today is try to push as many decisions as possible to later, keep the door open for futur choices. Every system architecture is part invention, part discovery. As you put together your foundation, new requirements/restrictions will appear and you'll be happy to have the freedom to make some of your decisions then.


I know you're asking for hands on, but if you want reading material: https://www.amazon.co.uk/System-Design-Interview-insiders-gu...

and

https://www.amazon.co.uk/Designing-Data-Intensive-Applicatio...

are great


google for "github system design primer" repository, youll get ideas


This one? https://github.com/donnemartin/system-design-primer

There's also a list here with more resource links: https://github.com/madd86/awesome-system-design


https://www.youtube.com/watch?v=bUHFg8CZFws

^ this guy is amazing. His systems are implemented all the time.


System design is very easy because you're always inheriting a prior design that exists in actuality or borrowing from a model. Just make sure the new design lowers cost, reduces complexity, improves security, and/or unlocks potential value. ;)

The best way to get hands-on practice is to do just that. The tech part of system design is nothing; it's dealing with an organization and its myriad biases, politics, and reservations that'll teach you the most about the practice.


I built a homelab server using a HP Elitedesk running Proxmox. Allows me to experiment with all kinds of tools which facilitate strategies for redundancy and scaling.


1. Build a naive system (without taking into account any requirements whatsoever) 2. Put the system in production 3. Get surprised that it works 3b. Or learn why it doesn't (likely not what you expected and would have designed for in stage 1)

Questions for stage 3: Do all customers/clients really need to be able to access all other customers/clients state/data in parallel and real time ? What can be cached ?


It takes time. Keep practicing by - re-reading, doing hands-on exercises. There are many fabulous resources shared by our fellow HNers. I think you got what you asked for!

Couple points from me:

Have someone conduct your mock interview, once you think you are ready. Also, don't hesitate from appearing in an interview at a company which you don't plan to join. Another good way to practice and demonstrate your skills.


For what purpose?

Are you a small business owner that preparing for going viral one day? Keep improving your system bit by bit. Maybe add a caching layer today, load balancer tomorrow, a job queue somewhere down the road and scale up your database now and then. And probably YAGNI imo.

If for job hunting, other comments had better suggestion


Are you trying to pass "system design interviews" . Those are more about putting on a oscar worthy performance desiging instagram with billion users in half hour. You just have to memorize all the patterns like cdn, dbsharding, cap theorem , geolocation alogrithms, queues and logs ect.


Grokking the System Design Interview is a good overview of the available templates/patterns/solutions. After that, block off 60 minutes with a whiteboard and ask yourself "How would I build $EXISTING_SERVICE from scratch?" Repeat regularly.


there are many answers to this, but i'll try to give a, although biased, straightforward example.

- learn docker / docker-compose - tie a websocket server, a task queue, and 2-3 http microservices together - you don't have to have many resources, maybe 4-5 endpoints that go through all services - have a client javascript front like react - (bonus for grpc communication for intermediary connections between microservices) - try to break it/ fix it as much as you can. - along the way you'll introduce yourself to timeouts, retries, rate limiting, and other secure practices.

watch guarav sen or hussein nasser on youtube - they are extraordinary resources for aspiring and even competent backend architects


I know you didn’t ask for this but Me and couple of my friends at big tech who have given and taken 500+ interviews, do mock interviews for each other and references.

For reference we do paid 45 mins mock interviews. In case you are interested, dm me and I can share more details.


There’s no dm on hackernews, can you share your email or something?


You don’t actually want that, I think. In practice systems start small, and stuff is added to them gradually. I consider this as a much bigger challenge than designing a “complex” system right from the start. The trick is to be able to keep a system clean over time, not to design it for a year and then just write down the code. So it’s fine to start with your small apps, but instead of throwing it away try to keep adding stuff to it and release more advanced versions say, every month.

That being said, there are a few well known examples of systems that are somewhat complex right from the start. Ecommerce comes to mind: build a configurable ecommerce framework that supports multiple stores, multiple vendors, multiple channels, CC and cash payments, multiple currencies, international delivery etc.


I write architecturenotes.co for this specific reason. Check it out.


learn how the framework you use works. find one that better fits your model of the world. build a big app on top of this framework.

do this with bigger & bigger end vision but with a doable MVPin mind.

look at good examples.

open source the result,

https://www.makepostsell.com/ (python, Pyramid, sqlalchemy)

https://www.remarkbox.com


By making a system ? Ultimately by knowing the problem hands on, one would be able to understand ( or appreciate ) the solution


Build a system. That's how you learn.


Yeah. Video games are very good at getting you to do this, and for teaching systems thinking.

Not directly related to any specific type of system, of course, but very good at getting you to build a system, maintain it, and fix any issues with it.

Factorio is an obvious example.


Play Factorio.


Build apps and play Zachtronics games


With your hands on it....




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: