Name: System Design Series: Taro Playlists [Part 7] - How Can Things REALLY Break?
Uploaded: 2022-10-25
Duration: 4 min 58 s
Description: Proactively talk about potential incidents when you are going through your system design

System Design Series: Taro Playlists [Part 7] - How Can Things REALLY Break?

Proactively talk about potential incidents when you are going through your **system design**. 

[Click here for Part 8, "Breaking Down The Work And Timeline".](https://link.jointaro.com/v8kxu9yzQkTYAr84A)

You can [find the full system design doc here](https://docs.google.com/document/d/15WaM8Ojan82g0m2mtz6kC2Hiyj0Q6VbjfqRmVNDI3qw/edit?usp=sharing) - Feel free to use it as a template for when you're designing systems at your job!

The tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:
- You should *always* think about "How can we cause a SEV?" when you're planning out any substantial project or task.
  - **Context:** SEV = Severity, which is the term Meta, Robinhood, and many other companies use to describe a really bad product event.
  - This is one of the purest and most critical manifestations of proactive thinking, which is one of the trademark attributes of a competent senior+ engineer and tech lead. SEVs are events that seriously set back your organization or even your entire company if they're something you have to react to as opposed to catching them early.
- This "anti-SEV" thinking is *especially* relevant for Big Tech where the stakes are much holder due to regulatory constraints, increased media presence, and a massive scale of users.
  - It's also far harder to do this well at Big Tech due to a greater range of ways things can break.
  - However, if you can do this well, you will add a tremendous amount of value to your team. This is why pretty much all senior and staff engineers at FAANG and FAANG-equivalent companies have really developed this skill.
- Here are the ways a SEV can happen from the video (these are all vectors Alex dealt with at Meta as well):
  - **Users not playing nice** - You should never assume that users will put in proper inputs or even not want to harm other users. Most major tech products have some sort of multiplayer component, so it's important to be vigilant here.
  - **Bad auth context** - This means that users are able to carry out actions on behalf of other users. This can happen either intentionally (i.e. the acting user is malicious) or accidentally (e.g. the user has multiple accounts on your service and switching between them cleanly is broken).
  - **Incorrect backporting** - "Backporting" is the process of making things work on older builds of your software. This is *very* relevant for mobile engineers as there will always be a good amount of users on older builds, especially if your product is used by people in regions with lower internet.

Proactively talk about potential incidents when you are going through your system design

Alex worked at PayPal and then as a tech lead across Course Hero, Meta, and Robinhood. He's now building Taro, empowering software engineers to be happier and more effective.

This collection represents the best of what Taro has to offer, personally curated by Alex and Rahul. If you're short on time, go through the content here.

System design is the process of determining the optimal high-level technical approach to a problem. It's a staple in both the interview process and actually doing your job as a software engineer.