Google system design interview: Design TikTok (with ex-Google EM)

Today's mock interview: "Design TikTok" with ex Engineering Manager at Google, Mark (he was at Google for 13 years!)

Or see more system design coaches:

Chapters:
00:00 Intro
00:58 Question: "How would you design TikTok?"
01:11 1. Clarification questions
07:42 2. Non-functional requirements
19:45 3. High level design (components)
22:50 3. High level design (upload flow with databases)
35:27 3. High level design (download flow)
45:47 4. Drill down (video metadata)
49:01 4. Drill down (user metadata)
51:24 4. Drill down (For You feed)
58:38 5. Bottlenecks
01:03:13 6. Enhancements
01:07:02 7. Bring it all together

About us:
IGotAnOffer is the leading career coaching marketplace ambitious professionals turn to for help at high-stakes moments in their career. Get a job, negotiate your salary, get a promotion, plan your next career steps - we've got you covered whenever you need us.

[johnangelo]

OK This Manager has very neat way of simplifying design. Good to have more videos from him.. (Youtube/Netflix)

[yinhuang]

Superb communication skills from Mark. Not that he is a fast or deep thinker but he clearly talks about where he is and slowly gets the destination. Like, "let me just make a quick detour here", "Let me put a placeholder here. I will get back to this" x 2. This makes him a good person to talk to. This is especially important for a EMs as they work daily with non-tech folks.

Some nickpickings, mostly from the tech side
1. spent a little bit too much time (15 min) on estimations.
2. started talking about details like cache without giving a big picture yet.
3. the amount of friendship data is domainated by the number of edges of the graph, not the number of verteces.
4. RDS horizontal scaling is only read-scaling by adding read replicas. It cannot scale with increasing number of friendships.
5. video history definitely does not belong to user metadata table. same for updaloed videos, screen time...
6.

[systemBuilder]

Sites like YouTube and Tiktok deliver videos adaptively using the DASH protocol to stream 2-second video segments over HTTP. This allows the delivery to work immediately over phones, without a long lagtime to build up a buffer, and the quality adapts if the channel capacity goes down. Typically the video will have 8-9 bit rates, anywhere from 128 Kbps to 2.5 Mbps for 1080p. You can see this on YouTube if you turn on "stats for nerds". Each file is sqrt(2) times larger than the last. So you might have 2.5 MB, 1.77MB, 1.25MB, 876KB, 619KB, 437KB, 309KB, 218KB, 150KB for 9 different bit rates. That sums up to about 8MB total for each video.

[Abay_Zhunis]

Great video! I think it would also be helpful to have a look at how Mark would design some real-time system (e.g. Online Auction). The focus imo should be on the immediate update and how this system would differ from regular auction (ebay)

[TechVenturer]

Mark: does that make sense ?
Interviewer: yeah that makes sense 🤔

[arshadhammad]

Thank you! I really enjoyed your video. The best part is the way he thinks about the system. His way is very systematic, he thinks ahead a lot of the aspects of the system. Which he later applied in his process, I am really grateful that I had the opportunity to see him think.

[JSXRP]

Cloudfront to mobile drops latency nearly an order of magnitude compared to direct S3 retrieval depending on your location and the S3 server location, but it will always be much faster. 

One thing to bear in-mind is Cloudfront has a built in dead-timer cache system, and when doing real-time S3 manipulations, the cache has to be configured to drop the previously most recent cached S3 object by key name in favor of, say, an uploaded object from 30sec ago, in order for the CDN URL to serve the 30sec ago object in real-time compared to the same S3 retrieval by key name. There is some cost there, but it is true that the CDN stores data close to local nodes and the benefits are awesome from an iOS developer's perspective

[tintintom]

Thank you. These are some interesting interview questions maybe you can consider as topics of interest - Design a metrics/monitoring system; Design Slack; Design logging system; Design a distributed Layer-7 api gateway ratelimiter . Thank you 🙏

[AndriyVorona]

I always wonder why on every system design interview people do back up the envelope calculations if none of those calculations are really used further on during the interview. Those don't even impact high-level designs in any way, because most designs end up resilient, scalable, highly available, etc.

[ashishism]

Though design looks plausible but it has couple of major flaws:
1. Dynamo parition and sort key. Having each addition key will increase the cost cost N+N.
2. User schema will likely not work for RDS where we are keeping track of watch history and user actively. 10K mutation/s is simply not scalable on RDS.
3. Interviewer hardly talk about how to fetch the videos in order which was on of the critical aspect.

[williamhom]

Been watching the videos on your channel and I think they're really good. However, it seems like they all represent "happy path" interviews, i.e., it seems like the "interviewer" is saying a lot of, "Yeah, that sounds right. That's good". I would love to see some examples of a "typical" interview and a "bad" interview where the interviewer does a lot more "work", so to speak.

[msysmilu]

Mark doing a perfect interview. Tom: "nice attempt" :))

[Svengtz]

Interesting stuff and the technical choices were on point! One thing i would Improve though is defining and slicing the requirements into bounded context related services. For example we could have defined the contexts: User, Video and Suggestor. Each would be represented by its own building block initially allowing to scale or break one up more, if needed. The suggestor then would have relations to User and Video and would (based on ML for example) generate video suggestions for different parts of the app. Video would be responsible for CRUDs on content and handle metadata and their blobs. The user would utlise this one when loading videos based on the suggestor result for example or the upload etc. The User context would handle user metadata, relations like friendship and possibly views. For each we can find specific solutions for their storage, scaling, concurrency etc. needs.

[konradte]

Way too much time spent on calculation. In th real interview it would be a definitive no-go. System design interviews usually last about 45ish minutes...

[panhejia]

great work. Very clear communication, and exposed thinking process and tradeoff. Plus one for the choice of DDB, S3 and CF. We are going full AWS suite LOL

[dontdoit]

Excellent! You can design this same system in GCP and Azure with very little modification.

[jonasliao]

I thoroughly enjoy these videos.
However, I'd love to see the interviewer drill down on some of the designs, as 99% of the time the interview here is driven by the interviewee. Sometimes the solution appears too high level, not staff+ level design.

[FurqanIqbal-dg]

This is great - it would be great if you can also have some Principal Mobile Engineers come on your channel and do a Mobile App Design/Architecture interview.

[rasoulabdulzahra]

this is soo good 👏 can you please do something about banking/fintech ??

[MrNinethsense]

`Great, I wish I can talk like Mark. He is my inspiration and man crush. Thanks Mrk.