4 ms·

Does anyone know of any good books for getting better at System Design that isn't web focused? Every time I look for "System Design" the books are about creatin

Does anyone know of any good books for getting better at System Design that isn't web focused? Every time I look for "System Design" the books are about creating a highly distributed web app with SQL or NoSQL database, load balancers, and other web centric stuff. I've spent most of my career fixing bugs or improving existing apps/systems in C++. Every time I interview somewhere they want me to design a (usually offline) program or service and I don't know how best to do that. At this rate I'll be stuck at Senior Engineer for the rest of my career. (I'm already 14 years in).

larve 4y ago
I learned a lot by writing "prototypes." If you look at system design and architecture from afar, they're all very simple patterns that can be written up in a self contained python or javascript program: * RPC = function call * API design = function signature * data schema = simple structs * message queue = list * load balancer = simple facade object * database = hash table / in memory SQLite Once you have a rough sketch in place, you can run your prototype and test different behaviours. It is a bit "tricky" to tackle asynchronous and concurrency, which you should do from the start. I prefer to do everything based on callbacks, and run my simulation from a static input list of events, ticking every component with a tick() method. This way I can generate different scenarios, save them to JSON, replay them. Here's some examples: - https://github.com/wesen/summer-pasture-netflix https://github.com/wesen/summer-pasture-netflix cell.py is a kubernetes prototype (blackboard system), while app.py is the start of the netflix event notification system. I am thinking of writing a course / book about the subject, and have a bunch of (wild) notes here: https://publish.obsidian.md/manuel/ZK/Structure+Notes/2+-+Software/2i0+-+Prototypes/SK+-+2i0+-++2022-08-13+-+Building+prototypes+for+software+architecture https://publish.obsidian.md/manuel/ZK/Structure+Notes/2+-+So...
- pramodbiligiri 4y ago
  This sounds like a great idea. If you can help simulate non-determinism and faults that will take it to the next level.
  - larve 4y ago
    I've used probability distributions to generate the incoming events, but the simulation is always deterministic. In the netflix case for example, I would generate 40% of users that would be playing things around 8am with a normal distribution, and 40% that would play around 8pm, and then 20% that play at random times of the day, etc... I also played with pymc3 where you can just place plain python inside your probabilistic model and MCMC the heck out of it. It's slow but you can use some real world input and see what distributions arise at each point of the graph.
- paulmilligrams 4y ago
  What a wonderful comment. I've bookmarked this page specifically to refer back to your list of simplifications and would encourage you to please begin on your book.
metageneralist 4y ago
What is the most difficult part for you in designing said program or service? I don't know about the book, but I think MATLAB Tech Talk about systems engineering might be a good start for you: https://www.youtube.com/playlist?list=PLn8PRpmsu08owzDpgnQr7vo2O-FUQm_fL https://www.youtube.com/playlist?list=PLn8PRpmsu08owzDpgnQr7... Part 3 is about designing a residential toaster :)
swatcoder 4y ago
Because C++ has been used in so many different domains and for so many decades(!), there are an overwhelming variety of architectures that have been deployed to great success in their own problem space. So I think you'll have a hard time finding resources until you narrow down what sort of things you'd like to be designing. You can spend years learning all about great design patterns that make sense for an IoT or embedded system but have completely backwards ideas about how to organize code for a game that needs to process 1000 unit movements per frame. But once you figure out some narrower domain that you like, you should be able to find books about it , (if you're good at reading code) can start studying open source approaches to it, and can start prototyping small projects to gain some hands-on experience and muscle memory.
blub 4y ago
I suggest learning an architecture framework which guides you on what topics to address as part of your architecture - such as 4+1, Viewpoints and perspectives or arc42 which I’ve learned of recently and seems to resemble the former. You’ll then mix domain-specific details into that framework. Systems design is for me quintessentially embedded system architecture for a microcontroller, a SoC or combination. It could be a smartphone or console, or medical device, etc. This is a very broad domain… in my case I work exclusively on non safety-critical SW, so I’ve focused on learning Linux internals and system programming which I combine with an architecture framework. Typically I design middleware and daemons which work together to cover a specific area of a product. I work with different kinds of specialists (HW, kernel, performance, etc) and a lead SW architect for each specific platform. The system architect is a different person that oversees both SW and HW and requires skills in both. For Linux I cand recommend the classics: Stevens, Kerrisk, Love. I found Chris Simmonds’ book to be a good general intro to embedded programming; it has much info which also helps with embedded system design. I’ve also picked up ideas from Making Embedded Systems by White or Embedded Systems Architecture by Noergaard. Application design refers to individual applications running on an OS. These are the typical MVC or layered architecture styles. The official OS UI framework will likely define a recommended architecture while headless services are quite flexible and support several architectural styles. Vol 1 of the Pattern Oriented Software architecture is a good intro. I have Software Architecture Patterns by Richards on my reading list, since it covers more recent styles like microservices.
zppln 4y ago
Perhaps you could narrow things down a bit by trying to figure out what key characteristics need to drive your design. I'm in aerospace. Some of the systems I stare at are designed pretty much exclusively based on safety considerations. Others are almost completely devoid of such considerations and more care is given to maintainability due to expected high rate of change, or requirements on throughput etc. Security is another joker with a high potential of impact on design. Also figure out what you consider to be "system design" as opposed to "software design".
TimButterfield 4y ago
You may wish to take a look at the book, Righting Software, by Juval Löwy. It is not specific to any particular application or language, but can be generally applied to different projects and systems. https://www.amazon.com/dp/0136524036 https://www.amazon.com/dp/0136524036
- blub 4y ago
  What insights did you get out of that? I was watching the video version and gave up because it was mostly fluff and self-promotion. Couldn’t even remember what the core idea was that he kept repeating.
  - TimButterfield 4y ago
    Here are just a couple of things. Often, decomposition is based on areas of domain or functionality. There are some downsides to doing it this way. The method in the book proposes it be based on areas of volatility instead. As an example, imagine writing a piece of software for FedEx shipping. What would change to use that same software for UPS instead? That may identify some areas of volatility. If you can plan that something might change, you can limit the ripple effect of those changes in future. Just an example of one benefit of doing it this way. The book explains some of how to approach designing this way. Another point: Architecture is not just about designing the software. It is also designing the project to build that software. This involves things like critical paths, staffing, risk management, etc. Understanding these is important if you want to be able to deliver on time and on budget.
    - blub 4y ago
      Thanks. Regarding the first point, I remember that he was very adamant that functional decomposition was a catastrophe, but I didn’t reach the part where he presented the solution, which based on your comment seems to be decomposing on volatility. I suppose it is another tool in the box, however in the video it was about to be introduced as nothing less than a magic bullet. Regarding the second point, I’m not sure I agree. An architect could get involved in staffing decisions and any project has a list of risks, for example I’ve maintained such lists as part of the architecture description. But I would define these these are side-tasks and not as core tasks.

larve 4y ago

I learned a lot by writing "prototypes." If you look at system design and architecture from afar, they're all very simple patterns that can be written up in a self contained python or javascript program: * RPC = function call * API design = function signature * data schema = simple structs * message queue = list * load balancer = simple facade object * database = hash table / in memory SQLite Once you have a rough sketch in place, you can run your prototype and test different behaviours. It is a bit "tricky" to tackle asynchronous and concurrency, which you should do from the start. I prefer to do everything based on callbacks, and run my simulation from a static input list of events, ticking every component with a tick() method. This way I can generate different scenarios, save them to JSON, replay them. Here's some examples: - https://github.com/wesen/summer-pasture-netflix https://github.com/wesen/summer-pasture-netflix cell.py is a kubernetes prototype (blackboard system), while app.py is the start of the netflix event notification system. I am thinking of writing a course / book about the subject, and have a bunch of (wild) notes here: https://publish.obsidian.md/manuel/ZK/Structure+Notes/2+-+Software/2i0+-+Prototypes/SK+-+2i0+-++2022-08-13+-+Building+prototypes+for+software+architecture https://publish.obsidian.md/manuel/ZK/Structure+Notes/2+-+So...

pramodbiligiri 4y ago
This sounds like a great idea. If you can help simulate non-determinism and faults that will take it to the next level.
- larve 4y ago
  I've used probability distributions to generate the incoming events, but the simulation is always deterministic. In the netflix case for example, I would generate 40% of users that would be playing things around 8am with a normal distribution, and 40% that would play around 8pm, and then 20% that play at random times of the day, etc... I also played with pymc3 where you can just place plain python inside your probabilistic model and MCMC the heck out of it. It's slow but you can use some real world input and see what distributions arise at each point of the graph.
paulmilligrams 4y ago
What a wonderful comment. I've bookmarked this page specifically to refer back to your list of simplifications and would encourage you to please begin on your book.

metageneralist 4y ago

What is the most difficult part for you in designing said program or service? I don't know about the book, but I think MATLAB Tech Talk about systems engineering might be a good start for you: https://www.youtube.com/playlist?list=PLn8PRpmsu08owzDpgnQr7vo2O-FUQm_fL https://www.youtube.com/playlist?list=PLn8PRpmsu08owzDpgnQr7... Part 3 is about designing a residential toaster :)

swatcoder 4y ago

Because C++ has been used in so many different domains and for so many decades(!), there are an overwhelming variety of architectures that have been deployed to great success in their own problem space. So I think you'll have a hard time finding resources until you narrow down what sort of things you'd like to be designing. You can spend years learning all about great design patterns that make sense for an IoT or embedded system but have completely backwards ideas about how to organize code for a game that needs to process 1000 unit movements per frame. But once you figure out some narrower domain that you like, you should be able to find books about it , (if you're good at reading code) can start studying open source approaches to it, and can start prototyping small projects to gain some hands-on experience and muscle memory.

blub 4y ago

I suggest learning an architecture framework which guides you on what topics to address as part of your architecture - such as 4+1, Viewpoints and perspectives or arc42 which I’ve learned of recently and seems to resemble the former. You’ll then mix domain-specific details into that framework. Systems design is for me quintessentially embedded system architecture for a microcontroller, a SoC or combination. It could be a smartphone or console, or medical device, etc. This is a very broad domain… in my case I work exclusively on non safety-critical SW, so I’ve focused on learning Linux internals and system programming which I combine with an architecture framework. Typically I design middleware and daemons which work together to cover a specific area of a product. I work with different kinds of specialists (HW, kernel, performance, etc) and a lead SW architect for each specific platform. The system architect is a different person that oversees both SW and HW and requires skills in both. For Linux I cand recommend the classics: Stevens, Kerrisk, Love. I found Chris Simmonds’ book to be a good general intro to embedded programming; it has much info which also helps with embedded system design. I’ve also picked up ideas from Making Embedded Systems by White or Embedded Systems Architecture by Noergaard. Application design refers to individual applications running on an OS. These are the typical MVC or layered architecture styles. The official OS UI framework will likely define a recommended architecture while headless services are quite flexible and support several architectural styles. Vol 1 of the Pattern Oriented Software architecture is a good intro. I have Software Architecture Patterns by Richards on my reading list, since it covers more recent styles like microservices.

zppln 4y ago

Perhaps you could narrow things down a bit by trying to figure out what key characteristics need to drive your design. I'm in aerospace. Some of the systems I stare at are designed pretty much exclusively based on safety considerations. Others are almost completely devoid of such considerations and more care is given to maintainability due to expected high rate of change, or requirements on throughput etc. Security is another joker with a high potential of impact on design. Also figure out what you consider to be "system design" as opposed to "software design".

TimButterfield 4y ago

You may wish to take a look at the book, Righting Software, by Juval Löwy. It is not specific to any particular application or language, but can be generally applied to different projects and systems. https://www.amazon.com/dp/0136524036 https://www.amazon.com/dp/0136524036

blub 4y ago
What insights did you get out of that? I was watching the video version and gave up because it was mostly fluff and self-promotion. Couldn’t even remember what the core idea was that he kept repeating.
- TimButterfield 4y ago
  Here are just a couple of things. Often, decomposition is based on areas of domain or functionality. There are some downsides to doing it this way. The method in the book proposes it be based on areas of volatility instead. As an example, imagine writing a piece of software for FedEx shipping. What would change to use that same software for UPS instead? That may identify some areas of volatility. If you can plan that something might change, you can limit the ripple effect of those changes in future. Just an example of one benefit of doing it this way. The book explains some of how to approach designing this way. Another point: Architecture is not just about designing the software. It is also designing the project to build that software. This involves things like critical paths, staffing, risk management, etc. Understanding these is important if you want to be able to deliver on time and on budget.
  - blub 4y ago
    Thanks. Regarding the first point, I remember that he was very adamant that functional decomposition was a catastrophe, but I didn’t reach the part where he presented the solution, which based on your comment seems to be decomposing on volatility. I suppose it is another tool in the box, however in the video it was about to be introduced as nothing less than a magic bullet. Regarding the second point, I’m not sure I agree. An architect could get involved in staffing decisions and any project has a list of risks, for example I’ve maintained such lists as part of the architecture description. But I would define these these are side-tasks and not as core tasks.