Use timer Design review -- or maybe make it as a separate topic page and then link here - are we doing POC or huge user base? - if doing huge user base, then what's the POC and learnings from it? - architecture always means you have trade offs. What's the trade off? what if you go one way or other? why did product choose one way and not other? - if you're designing for something that will trigger a different / new user experience over an established flow: then always add A/B. - Are you doing something to solve a problem: Identify ways to extract impact metrics - sync vs async processing You want to get as much critical feedback as early as possible. You cannot do anything once your code hits the prod. * If you got no reviews, you didn't need any design review * If your design review complete fails, there is a problem with the purpose of your project Start with important, and risky and controversial parts; for riskier parts - do more of it not less. * You want to confirm what is important is really important, and not that something you thought is unimportant is actually important. * You want to let everyone have some background, but also not want to spend time on non-controversial ideas. Try to group non-controversial ones for follow up later in meeting, or say, you'll reach out separately. But don't use this to sweep off any controversial idea. If someone still insists, ask them what's the controversy here Do bunch of small review rather than a big review. Start with a small review on what is your goal of project. Make sure your goal on what you're trying to solve is correct. Make any implicit thing explicit. Propose multiple options that could be right; and objective way to evaluate: have an objective for what's good for company and not just because it sounds right. With this, don't just say one thing and run with it Understand at high level, not nitty gritty details Exit criteria, or what is result of design review: * Don't ever expect or commit to others - that you'll be changing design based on comment * Ideal should be: these are some great suggestions, I'm gonna assign myself or others to look into it. That way, the design review is just there for suggestions but nobody commits. You assign tasks. later, when heat f moment is gone, then you can take a step back and analyze!! Good design review is when you have follow up tasks and you assign to yourself or to others When writing design (i.e. even before review starts, just making doc) - do pair writing - and/or - run it internally like a mini design review architecture interview: - you cannot solve it because the question will always be undefined. So, don't think that way - ask interviewee if the design in for POC or high user. This is a trick question: if interviewee says high user, then ask them what was POC design and findings. Before they realize what happened, say that you'll start with POC and will then do high user. If they insist high use.. then ask what all factors contribute to high use: more users, different geographic location, different countries. What is causing bottleneck? - Based on above, always think of starting with POC.. hence, always start with normalized db design. Also, going from normalized to denormalized design is easy.. but not the other way - If you aren't able to identify any "unique" combination in db.. that's a sign to use messaging (MQ or Kafka) - As mentioned above, as application goes from POC to high use.. it'll know of bottlenecks that would need to be optimized away either by improvement on existing behavior or having new behavior. Identify what you want to optimize? What is something that will get hurt by this optimization? One way to optimize is by going from exact behavior to "being in a tolerance". How much tolerance in a metric is allowed? Tolerances can enable you to make a lower complexity solution - Clarify requirements.. and in doing so, don't just ask question to get answer.. but also do what if this different thing, or this opposite thing? Why not? - If you interviewer said: is there anything i can clarify.. it means they are expecting you to ask question. On flip side, if you don't want to or cannot think of any - then tell them that you'd like to slowly work on the requirements and clarify if you see a roadblock. It's software, and ideally everything should be reversible given enough time and money. So, when a choice constraint would show up, you'll check with them on requirements. Technology: REST vs GraphQL; SQL vs NoSQL; DB or Message queue; Logging; Monitoring; resilience architecture goal: everything is reversible.. but at cost. Make sure to hash out big cost items. Particularly, if you may be overlooking something think of trade-offs, not correct/wrong self: -- NoSQL: is data columns changing - but using single store; do we want low latency and allow for application centric approach; not good for mvp -- REST vs GraphQL.. streaming file vs polling vs server-send-response vs websocket -- distributed db (cap); acid; NoSQL doesn't mean CAP -- routing should be context based -- generally that means user based if workflow can having multiple paths.. leads to caching -- understand diffreence between library and framework: jquery is library; react is framework. Libraries are generic, good for poc. Framework are opinionated. best for big operations and based on support available. -- sync vs async processing -- event driven vs request-response model -- api documentation -- db schema -- system monitoring vs application logging vs metrics -- scaling (in a way so that it does not lose benefit from one stage to next processing stage), recover -- io vs compute intensive; is a short term or long term io? let aws optimize -- on transaction fail? repeat failures and retry exhausted -- places to get metrics (different from monitoring) -- a/b test -- microservice -- cron job -- related functions (like to view stocks, there is buy stock function) -- authentication -- JWT or cookie -- CORS -- localstorage (for UI) -- pagination for REST -- ask product qs.