I have build many small size web apps.<p>I lack experience in designing medium to large application. I tried to read system design content but not able to gain confidence.<p>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<p>1. That has a functioning app<p>AND<p>2. Business is growing rapidly bringing more customers than the system can handle.<p>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.<p>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.
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.<p>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).<p>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]<p>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.<p>1: <a href="https://www.nonattached.net" rel="nofollow">https://www.nonattached.net</a>
2: <a href="https://cloud.google.com/blog/products/management-tools/sre-principles-and-flashcards-to-design-nalsd" rel="nofollow">https://cloud.google.com/blog/products/management-tools/sre-...</a>
Work through these books, then you start looking at any random app or system and can start from there:<p>- System Design Interview – An insider's guide: <a href="https://smile.amazon.com/gp/product/B08CMF2CQF" rel="nofollow">https://smile.amazon.com/gp/product/B08CMF2CQF</a><p>- System Design Interview Vol 2: <a href="https://smile.amazon.com/System-Design-Interview-Insiders-Guide/dp/1736049119" rel="nofollow">https://smile.amazon.com/System-Design-Interview-Insiders-Gu...</a><p>- Designing Data-Intensive Applications: <a href="https://smile.amazon.com/gp/product/1449373321" rel="nofollow">https://smile.amazon.com/gp/product/1449373321</a><p>- System Design Primer: <a href="https://github.com/donnemartin/system-design-primer" rel="nofollow">https://github.com/donnemartin/system-design-primer</a><p>Especially: <a href="https://github.com/donnemartin/system-design-primer#how-to-approach-a-system-design-interview-question" rel="nofollow">https://github.com/donnemartin/system-design-primer#how-to-a...</a><p>- The Architecture of Open Source Applications: <a href="http://aosabook.org/" rel="nofollow">http://aosabook.org/</a>
Hmm. I think you might be getting at two different questions.<p>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.<p>Two: How do you get better at systems design <i>interviews</i>? 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.<p>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.<p>There are some common resources recommended for this sort of thing if you want to also make sure you've read the <i>right</i> content. The most helpful resources for me were the DDIA book [1] and the "Systems Design Interview" YouTube channel [2]. Both are great for <i>breadth</i> and getting exposure to a ton of different concepts -- after that, you can follow your nose (or the book's bibliography) to get <i>depth</i> on whatever you're most interested in.<p>Good luck with it! It's a deep and really fun rabbit hole. I suggest you find a particular <i>type</i> 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.<p>[1]: <a href="https://www.amazon.com/gp/product/1449373321/" rel="nofollow">https://www.amazon.com/gp/product/1449373321/</a><p>[2]: <a href="https://www.youtube.com/c/SystemDesignInterview" rel="nofollow">https://www.youtube.com/c/SystemDesignInterview</a>
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<p>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’.<p>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.<p>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…:)<p>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).<p>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 :<p>1. Almost all distributed systems has a global load balancer sitting in front, which will distribute your traffic to nearest possible server.<p>2. Decide how do you want to make your DB replication to happen. Is it active/active, active/passive, P2P, etc ?<p>3. What do you choose between Consistency and Availability when Network Partition happen? Some databases like Cassandra are eventual consistent.<p>4. Any asynchronous tasks will need to use queuing service.<p>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:<p><pre><code> - 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
</code></pre>
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.<p>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.<p>There will be `Main Quests` where we build a simple game, and `Side Quests` where we go off the wall and explore new tech.<p>I just started tonight! So it's definitely a WIP<p><a href="https://mikercampbell.gitbook.io/gotta-code-them-all/" rel="nofollow">https://mikercampbell.gitbook.io/gotta-code-them-all/</a>
Don't underestimate how much what you can learn building small apps will scale up to bigger ones.<p>The great thing about smaller projects is that you can take risks with them.<p>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.<p>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:<p>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.<p>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.<p>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.
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].<p>[0] <a href="https://locust.io/" rel="nofollow">https://locust.io/</a><p>[1] <a href="https://github.com/asatarin/testing-distributed-systems" rel="nofollow">https://github.com/asatarin/testing-distributed-systems</a>
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.<p>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.<p>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:<p>* 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<p>* Allow users to register and create their own counters<p>* Store the counter value in database hosted somewhere<p>* Store content stuff (title, labels, etc.) in a headless CMS and integrate with it.<p>* Set up build pipelines for your project<p>* ...and more :)
Checkout highscalability.com, used to have lots of real word scalability issues and solutions back on the day.<p>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.<p>At the very least you’ll get hands on experience.
The thing that helped me the most to design maintainable systems was the use of Clean Architecture. In particular, the [Cosmic Python Book](<a href="https://www.cosmicpython.com/" rel="nofollow">https://www.cosmicpython.com/</a>), 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_.<p>[0] <a href="https://nealford.com/katas/#:~:text=Architectural%20Katas%20are%20intended%20as,the%20facilitator%20for%20the%20exercise" rel="nofollow">https://nealford.com/katas/#:~:text=Architectural%20Katas%20...</a>.
Practical ideas off the top off my head:<p>Take a fast moving input data stream, and map it to some slower moving output streams.<p>Use a message queue, a web tier, a worker, and implement private and public caching internally in something like Redis. Implement HTTP caching.<p>Implement backups, failover, and recovery. Create runbooks and checklists.<p>Secure everything with MFA auth for admin-type users and design and implement lesser privileged user access.<p>Design and implement RBAC.<p>Add reporting, logging, fault-tolerance.<p>Make it platform agnostic and support multi-tenancy, i18n, and WCAG.<p>Support and test for HIPAA and GDPR compliance.<p>Document the whole thing.<p>Figure out how to write automated tests for all of these aspects.
I've done a couple. I'm working on one, right now.<p>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).<p>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).<p>My way won't win Buzzword Bingo, but it WFM. YMMV.<p>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.<p>[0] <a href="https://littlegreenviper.com/miscellany/" rel="nofollow">https://littlegreenviper.com/miscellany/</a>
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.<p>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.<p>So asking lots of questions about what they want is probably a first.
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).<p>Ask yourself:<p>- What constitute a _good_ infrastructure?<p>- Something flexible/adaptable ?<p>- Something predictable ?<p>- Something resilient ?<p>- Something easy to monitor ?<p>- Something else ?<p>- How do you prioritize these, who gets to decide which one matters most...<p>Architecture is asking a lot of questions, inviting others who will benefit/use your work into the decision making process.<p>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:
<a href="https://www.amazon.co.uk/System-Design-Interview-insiders-guide/dp/B08B35X2ND/ref=asc_df_B08B35X2ND/" rel="nofollow">https://www.amazon.co.uk/System-Design-Interview-insiders-gu...</a><p>and<p><a href="https://www.amazon.co.uk/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321/ref=asc_df_1449373321/" rel="nofollow">https://www.amazon.co.uk/Designing-Data-Intensive-Applicatio...</a><p>are great
<a href="https://www.youtube.com/watch?v=bUHFg8CZFws" rel="nofollow">https://www.youtube.com/watch?v=bUHFg8CZFws</a><p>^ this guy is amazing. His systems are implemented all the time.
System design is very easy because you're <i>always</i> 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. ;)<p>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 <i>not</i> what you expected and would have designed for in stage 1)<p>Questions for stage 3: Do all customers/clients really need to be able to access <i>all</i> 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!<p>Couple points from me:<p>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?<p>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.<p>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.<p>- 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.<p>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.<p>For reference we do paid 45 mins mock interviews. In case you are interested, dm me and I can share more details.
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.<p>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.
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.<p>do this with bigger & bigger end vision but with a doable MVPin mind.<p>look at good examples.<p>open source the result,<p><a href="https://www.makepostsell.com/" rel="nofollow">https://www.makepostsell.com/</a> (python, Pyramid, sqlalchemy)<p><a href="https://www.remarkbox.com" rel="nofollow">https://www.remarkbox.com</a>