Identifying Constraints

A constraint is a condition the solution must accept as given, which no design choice can trade away. It is imposed from outside the design: by the business, such as a budget or a launch date; by regulation, such as PCI DSS or data residency; by technology, such as an existing system of record or a mandated cloud; by the organisation, such as team size and skills; or by operations, such as maintenance windows and support model. In an interview, constraints narrow the solution space and should be identified in the first few minutes, because an elegant design that breaks a stated constraint loses credibility, however good the rest of it is.

A requirement describes what the system must do or achieve, such as handling ten thousand orders per second or keeping p99 latency below 500 milliseconds; a constraint limits how it can be built, such as data staying in India or the company using AWS only. Requirements can sometimes be traded against each other or renegotiated with stakeholders, for example accepting 99.95 instead of 99.99 percent availability. Hard constraints cannot be traded at all; they simply remove options. Assumptions are a third category, beliefs such as ten million daily users that you have not confirmed. Keeping the three separate on the whiteboard makes your reasoning visible and lets the interviewer correct you early.

The usual types are business, regulatory, technical, organisational and operational. Business constraints include budget, deadlines tied to events such as a festival sale, and contractual obligations. Regulatory constraints cover PCI DSS for card data, privacy law such as DPDP or GDPR, data residency, health-data rules and financial regulation such as audit retention. Technical constraints include existing systems of record, mandated clouds and standards, legacy protocols and third-party rate limits. Organisational ones are team size, skills and structure. Operational constraints are on-call availability, maintenance windows and support models. Asking about each category in turn is a quick checklist that ensures nothing important is missed in the clarification phase.

Because many stated constraints are really preferences, and designing around a preference can rule out the best option for no reason. A hard constraint comes from law, contract or physics and cannot change; a soft one is a strong preference, standard or habit that could change with a good justification. Verify with short, respectful questions: is that fixed or a preference, does the standard apply to new systems as well as existing ones, is the deadline tied to an external event? Told "we use Oracle", one candidate asked whether that applied to a new high-write location service; it did not, and a time-series store was accepted with a clear rationale.

PCI DSS means card data should stay out of your systems wherever possible, because everything that stores, processes or transmits card numbers falls into PCI scope, with heavy controls and audits. The standard design is tokenisation through the payment service provider: the client sends card details directly to the PSP using its hosted fields or SDK, and your services only ever see a token. That keeps your platform out of most of the scope and removes the need for your own HSM and key management for card data. Where some components must handle card data, isolate them in a segmented cardholder data environment with strict network controls, encryption, logging and access reviews.

Team size limits how many moving parts the organisation can build, run and support. A team of five to eight engineers cannot sensibly own twenty microservices, each with its own pipeline, dashboards, on-call rotation and upgrade work. Small teams should favour a modular monolith or a handful of services, managed databases, queues and container platforms, and a stack they already know, typically Java and Spring Boot, rather than a new language. A team of six without Kubernetes skills is well served by a modular monolith on ECS or App Runner with managed PostgreSQL and SQS. Larger organisations with separate domain teams can justify more services aligned to those team boundaries.

Surface the conflict explicitly, explain the trade-off with numbers, propose options and let the interviewer, acting as the business owner, decide which constraint gives. For example: we need 99.99 percent availability but only one region is allowed; multi-AZ with good engineering gets us to roughly 99.95 percent, while 99.99 usually needs a second region, so which should give? Other common conflicts are a three-month deadline against a full feature list, resolved by an MVP scope, and a tiny budget against heavy compliance, resolved with managed compliant services and less regulated data. Silently picking one constraint looks like you missed the tension; naming it shows senior judgement.

They let you eliminate options quickly and justify every choice you keep. Instead of comparing every possible datastore, you strike out those that violate a constraint: a self-managed Cassandra cluster is out because there are no dedicated database operations staff, a global multi-region database is out because data must stay in India, and a new vendor's product is out because procurement takes four months. Only the survivors, such as Aurora PostgreSQL and DynamoDB, are compared on quality attributes. This two-stage reasoning, feasibility first and fitness second, saves interview time, keeps the design grounded, and gives a ready answer whenever the interviewer asks why you did not choose something else.

Solution architect interviews add delivery and enterprise constraints that senior engineer interviews often skip. Existing vendor contracts and licences shape build-versus-buy and exit options. Enterprise architecture standards and approved technology lists define what can be used without exceptions. Procurement lead times, often three to six months for a new vendor, push toward existing vendors or the cloud marketplace. Change freeze windows, such as year-end or festival freezes, drive release and migration plans, and budget cycles determine how investment is phased, for example an MVP in phase one and scale-out in phase two. Mentioning these unprompted shows you think about how a solution actually gets delivered inside an organisation.

The classic mistake is designing the ideal system while ignoring a constraint the interviewer stated earlier. A candidate proposes multi-region active-active across India and Singapore after being told that data must stay in India, or twenty microservices for a team of five, or storing card numbers in the orders database. Even if the rest of the design is excellent, it signals poor listening, and interviewers deliberately test this. The protection is simple: write each constraint in a corner of the whiteboard as soon as you hear it, refer to it whenever you make a choice, and finish by recapping how the design respects each constraint, including any introduced late.