Does it makes sense to add two-three different types of databases in one design interview?
Let say for a social media design, - I want to add a graph database to maintain followers-following data. - MongoDB to store list of posts a user should see on their timeline. - The User and posts date in an RDBMS.(Probably, this could also be added in graph database itself). Will the above perspective work towards my favor or will it be counter-productive? #systemdesign #interview
It will work towards your favour, as long as you are able to explain your choice of choosing the db for the instance
i've built an app with social network features in it (it was small and never took off massively) and this was roughly the approach we took, so yeah it works and IMO you're on the right track. there are three big problems with this: 1) that's a lot of infra and complexity - all of those tools require careful administration to scale cost-effectively and social apps typically don't make a ton of money so using managed public cloud service forms of these tools is likely not cost effective. realistically, you'll have a team that's more comfortable with one of the three, and these tools are USUALLY flexible enough to hold data that would be ideally modeled in some other tool. you probably want to start with just one, per your team's preference and expertise, and introduce other tools gradually as needed to scale. you'd be surprised how much performance you can get out of a good RDBMS. it's a different story if you're interviewing for a megacorp that expects massive scale from day 1 though. 2) you're specifically asking in the context of a design interview. most design interviewers have never actually designed a distributed system. they will evaluate you based on their own personal values which are most likely not grounded in what the better engineering tradeoffs are, but on their personal tech preferences. some interviewers think SQL is impossible to scale so they'll consider you incompetent for even suggesting it in ANY part of your design. some are RDBMS diehards and will think you're a stupid hipster for going for a document store (also, see point 3 below). very few engineers have actually ever touched a graph database and probably only know them from seeing them mentioned superficially in DDIA or whatever (and tbh, they're often shit - i did a ton of benchmarking for social graph storage/querying with many graph databases and for the specific query patterns we needed, it was 10x faster and cheaper to just put our graph in a RDBMS) - so if you get a nonexpert, it's a tossup (maybe they're surprised, maybe they're skeptical), and if you get an expert, you better be ready to justify why you have a query pattern that justifies using a graph database. i would grill you on this lol 3) mongo is bad. like really bad. like eats-your-data bad. maybe this isn't true anymore, idk, it's been a while. it's more important to make sure you're aligned with your interviewer's values than to have specifically a great architecture in your solution. it's all about how you explain/justify your decisions.
Thanks for the detailed info Google. If I use RDBMS, I would normalize the follower data into a new table and build materialized views to fetch the recent followers. This way I will not run complex join query; update views for every 1 hour or so. I remembered MViews because of your comment Tq.
Gives you an opportunity to talk about CAP theorem
If you can justify it, then yes. But remember that the system design is about tradeoffs. Make sure you offer multiple alternatives that you considered and why you are leaning towards this.
Why 3? Why not just 10? Practice high judgement and don’t include any comparison that adds no value to your proposal.
yeah
Do you mean it will be against my favor?