With that being said - when it comes to tackling these interviews - it seems that most of the time I am trying to regurgitate information rather than actually doing some kind of "problem solving".
The other end of this would be to read many System Design Interview Answers and learning those - and then knocking on wood and praying that you're going to get one of those questions.
Neither of these sound very productive.
How would one be able to answer such questions with confidence if they have never build out those systems? And what would be the preparation needed to be able to do that?
Better yet, why not look at the person experience and ask them how would they scale a system they actually worked on before? And what were the tradeoffs.
This can be helpful for LARPing though: https://systemdesignfightclub.com/
The interviewer knows you don't have personal experience building Dropbox, but a systems design interview question might be help me build Dropbox, for cats. Half of it is regurgitating information - what database would you use, Redis vs Mongodb vs Dynamodb vs Postgresql vs Spanner vs BigQuery vs BigTable vs Firebase, but more importantly, you need to show that you know the bigger concepts; relational vs key-value vs document store, and their trade-offs.
The interview is 45 minutes to see how you think, how you react to questions, how you behave as a human being, what happens when I throw in a curve ball. If I say your design is stupid, do you get mad and start yelling at me and call me names, or can you incorporate that feedback and adjust your design to accommodate a change in behavior.
Get to know the building blocks very well.