The Senior Engineer’s System Design Checklist: 50 Questions to Ask Before Finalizing an Architecture
Fifty Questions a Senior Engineer Runs Through Before Committing to an Architecture, Organized by the Areas Where Designs Most Often Fail
There is a moment in every design process when the architecture feels finished.
The components are chosen, the diagram is clean, and the team is ready to start building. This moment feels like progress, and the temptation is to move straight into implementation.
Experienced engineers treat this moment differently. They know that the cost of a flaw in an architecture grows enormously the later it is found.
A gap caught during design costs a conversation, while the same gap caught after launch can cost weeks of rework, an outage, or a rewrite.
So before finalizing, a senior engineer runs the design through a deliberate review, asking a series of questions designed to surface the problems that are invisible when a design merely looks complete.
The difference between a junior and a senior approach is not the initial design, since both can produce something reasonable.
The difference is this review.
A senior engineer knows which questions to ask, where designs commonly fail, and how to pressure-test an architecture against the realities it will face. These questions are not academic. Each one corresponds to a way that real systems break, run over budget, or become painful to operate.
This article is that review, captured as a checklist of fifty questions organized into the areas where architectures most often fall short.
The questions span requirements, data, scaling, reliability, consistency, security, operations, and cost. For each, the point is not a single correct answer but whether the design has a deliberate answer at all.
A design that can answer all fifty is far more likely to survive contact with production than one that has never been asked.
How to Use This Checklist
Before the questions, a note on how to apply them, because a checklist used poorly becomes a box-ticking exercise rather than a real review.
The goal is not to have a perfect answer to every question, since many answers will be deliberate trade-offs or accepted risks.
The goal is to ensure that every question has been considered, so that nothing important is left to chance. A design where a gap is a conscious decision is healthy, while a design where a gap is an oversight is dangerous, and these questions turn oversights into decisions.
Not every question applies to every system, so use judgment about which matter most for a given design.
A small internal tool needs a lighter review than a system handling payments for millions of users. The categories help here, letting you focus on the areas most relevant to the system at hand. With that in mind, here are the fifty questions.
Requirements and Scope
The most common cause of a failed design is solving the wrong problem, which makes requirements the first thing to pressure-test.
1. What exactly is this system supposed to do?
Confirm the core functional requirements are clear and agreed, because a design built on vague requirements solves a problem nobody asked for.
2. Who are the users and how many are there?
The number and type of users shape every scaling decision, so an unclear audience means an unsized design.
3. What is the expected scale, in users, requests, and data?
Concrete numbers for traffic and storage are needed, since a design that works at one scale often breaks at another.
4. What are the non-functional requirements?
Clarify the targets for latency, availability, and throughput, because these constraints determine whether a given design is even acceptable.
5. What is explicitly out of scope?
Naming what the system will not do prevents over-engineering and keeps the design focused on what actually matters now.
6. What are the read and write patterns?
Knowing whether the system is read-heavy or write-heavy drives database, caching, and scaling choices, so an unknown ratio leaves those choices unguided.
7. Which requirements are most likely to change?
Identifying the parts most likely to evolve tells you where the design needs flexibility, so a future change does not force a rewrite.
Data and Storage
Data decisions are among the hardest to reverse, which makes them deserving of careful scrutiny before finalizing.
8. Is the database choice justified by the data and access patterns?
Confirm that the choice between relational and non-relational fits the actual data, rather than being a default or a familiar habit.
9. What is the data model, and does it support the main queries?
The schema should support the queries the system actually runs, because a model that does not fit its queries forces painful workarounds later.