
System Design Interview Cheatsheet - jsfatigue
https://gist.github.com/vasanthk/485d1c25737e8e72759f
======
jasode
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.

------
andrewstuart2
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. :-)

------
srrm_lwn
More links here - [https://github.com/checkcheckzz/system-design-
interview](https://github.com/checkcheckzz/system-design-interview)

~~~
ncr100
Looking also for a Random System Design Generator with buzzwords and diagrams,
for entertainment.

~~~
Erwin
You can join the "Agile Release Train" right here:
[http://www.scaledagileframework.com/](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".

------
aryehof
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.

------
Spearchucker
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...](https://www.wittenburg.co.uk/Entry.aspx?id=d8c54975-bd0a-410b-b266-d73c1f45c641)

Lastly, privacy and data protection aren't mentioned at all, which is
absolutely mandatory for me.

------
bottled_poe
In my opinion, ability to describe and define interfaces (i.e. how different
components interact) is mandatory.

~~~
joshvm
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.

------
sudeepj
This is useful to demonstrate that as a candidate I have considered the
aspects mentioned in the link. It may give a completeness feel to it.

Sure there are more things to add (like identifying key interfaces) as others
have mentioned here. This is a nice starting point though.

------
coolmints
Great list! Would love to see some example design questions worked out using
this approach.

------
tamana
The reference to "inheritance" seems bizarrely out of place.

------
yangdehua
no docker?

------
yangdehua
good work! thanks so much..

