This list is missing "costs" as an explicit tradeoff parameter. Costs are an inherent part of technical design and also with later refinements to the capacity planning in spreadsheets.
For example, you want to be able to link revenue (user counts, advertising impressions, etc) to infrastructure costs. This could have ripple effects throughout architecture such as deciding between AWS S3 storage vs buying hard drives by the pallet and installing them in your own data center. This could later affect web clients such that your javascript code restricting users from uploading photos larger than 1024x768 pixels because your IT staff can't install/format raw harddrives fast enough for huge 10MP images.
In other words, technical choices affect costs, but simultaneously, knowledge of costs also drives the technical choices.
Technical architects can focus on factors like latency, redundancy, MTBF, bandwidth, watts, etc but they also have to have a parallel mindset of the "business spreadsheet". Your CEO/CFO is going to ask about it anyway because $$$ is a constraint on what's feasible to build. E.g. you can present System Design Option #1 that costs $5 million based on X assumptions or Option #2 that costs $10 million based on Y assumptions.
Wait, system design interview or just system design? Seems like a great outline for starting or evaluating any system, and includes a lot that, in my experience, can be missed by experienced architects. I'm sure that's great for interviews too, but IMO it's a good bookmark for just everyday system design, even if you've already got the job. :-)
You can join the "Agile Release Train" right here: http://www.scaledagileframework.com/ -- all the "lead-agile leaders" are on it, and they're taking off on the "architectural runway", as soon as its "value stream" has reached the right "cadence".
A great deal of focus on non-functional requirements, technology and infrastructure.
However, there is little mention of the criteria that can affect system design, taking into account the shape of the problem under consideration and functional requirements.
Driving system design will be:-
- domain complexity
- whether domain in business, commerce and industry, versus computer and data sciences
- whether the representation of the problem is best suited to a simple procedural approach, a structure programming using functional decomposition approach, an object domain model, or a data-driven approach.
It's a good list, and there are questions on there I don't usually ask but should (testing and process). That said, I like to spend time on quality objectives (portability, flexibility, integrity, interoperability, reliability, robustness and so on). Even if they're not applicable, it's good to know they're not. My quality cheat sheet is here https://www.wittenburg.co.uk/Entry.aspx?id=d8c54975-bd0a-410...
Lastly, privacy and data protection aren't mentioned at all, which is absolutely mandatory for me.
I was asked an interface question in a recent Big 4 interview, not a system design one (even though I was told one interview would explicitly be system design). Though perhaps it depends on your experience, as a fairly recent graduate, if I was asked how to design a big web service I would be answering by rote so it wouldn't be much of an indicator.
For example, you want to be able to link revenue (user counts, advertising impressions, etc) to infrastructure costs. This could have ripple effects throughout architecture such as deciding between AWS S3 storage vs buying hard drives by the pallet and installing them in your own data center. This could later affect web clients such that your javascript code restricting users from uploading photos larger than 1024x768 pixels because your IT staff can't install/format raw harddrives fast enough for huge 10MP images.
In other words, technical choices affect costs, but simultaneously, knowledge of costs also drives the technical choices.
Technical architects can focus on factors like latency, redundancy, MTBF, bandwidth, watts, etc but they also have to have a parallel mindset of the "business spreadsheet". Your CEO/CFO is going to ask about it anyway because $$$ is a constraint on what's feasible to build. E.g. you can present System Design Option #1 that costs $5 million based on X assumptions or Option #2 that costs $10 million based on Y assumptions.