World Conflicts
Yesterday
285
Since people still can’t wrap their minds around the fact the Gaza death toll hasn’t changed
Tech Industry
Yesterday
3618
Job market is brutal for SWEs 🥲
Tech Industry
Yesterday
1761
Meta E6 offer.
Tech Industry
Yesterday
324
How many times have you gotten laid off before?
Tech Industry
6h
1081
How bad is it in meta?
I have ~4.5 years of experience and have an on-site with Stripe coming up in the next several weeks. I currently work at a major (non-FAANG) company and have exposure to large scale systems, however I've still done/am doing the following: 1) Read "Designing Data Intensive Applications" front-to-back 2) Grokking the System Design Interview 3) Systems Design Interview Book 4) System Design Primer 5) Various YouTube videos However, one thing I've noticed is that in the YouTube videos I've been watching and even some of the reading materials with actual System Design questions, the estimations (storage, memory, etc) typically done at the beginning of the interview range widely among the above resources. I've never done a System Design interview before since I've held my job since college, but could someone opine on the actual level of "back of the envelope cancellations" that are expected for these interviews? None of the popular system design interviews do the same sort of in-depth analysis "Grokking The Systems Interview" exercises do - e.g. computing # of bytes needed for a unique integer ID (for example). To me I would just say "we would use an appropriate UUID" and move on instead of spending so much time calculating out numbers or is this wrong? Is there a general consensus on this? #systemdesign #stripe
The point of doing these calculations is to make sure whatever you design will be able to support requirements. It's not juat for the sake of doing it.
There's no consensus and it entirely depends on context. I think it is a good idea to try and spend about 5 minutes on the calculation, using pre-stablished concepts to get your numbers. For example, lets say you have 1M daily active users. You can ask at the start if it is geographically distributed around the world or not. If it's all in the same location, you can consider a traffic peak (worst case) of 1M concurrent requests, otherwise this os much more dilluted (e.g. a bushit number like 100k). The important thing is that calculations allows you to show you make sensible choices and have some idea about how systems are scaled in the presence of a certain user base and features. That being said, some problems require more calculations than others, specially if you need to change what tech you use depending on the data traffic (e.g. kafka instead of rabbitmq due to an enourmous scale). I always try to at least calculate: bandwidth, payload size, db storage (1 day/5 years), file storage (same) and requests per second, always in 5 minutes ot less, so not super precise and a bit formulatic.
Thanks, that’s actually super useful. Is it appropriate to ask upfront questions like “are we striving for a weak/eventual/strong” consistent system, or is that jumping the gun and should wait until actually designing sub-components?
IMO whether a system is weak/eventual/strong consistency has more to do with the product rather than what the interviewer wants to see, that is, it is something to decide, not to ask. For example, you are designing a multi-service system and while doing a critical transaction, you want to update a non critical piece of data. You can describe it can be solved in two different ways (synch/asynch), list pros and cons and choose. This gives you a chance to discuss trade-offs and show design knowledge. You can, however, ask this indirectly, e.g.: what is the max desired latency? How fault intolerant are we? Sometimes that should be obvious depending on the product, but when not, ask those questions and use the answers to modulate your design and trade-offs.