Search the practice set
126 questions, 454 terms and 400 topics in 20 areas.
60 results for “VPC Design”
Domain-Driven Design
Modelling software around the business domain, with boundaries drawn where the language of the business changes.
Privacy by Design
Building privacy protections into a system's structure from the start, rather than adding controls to a design that already collects and keeps everything.
Abstraction
Exposing what a component does while hiding how it does it, so callers depend on the contract rather than the mechanism.
Architecture Cost Model
A calculation, made during design, of what an architecture will cost to run at expected and at peak volume.
Architecture Principle
A durable, agreed rule that constrains design decisions in advance, stated with its rationale and its implications.
Architecture Review Board
A forum that reviews significant designs against standards, risks and strategy before commitment.
Cohesion
The degree to which everything inside one component belongs together and changes for the same reason.
Coupling
The degree to which one component must know about, or change alongside, another.
Fail-Fast vs Fail-Safe
Whether a component should stop immediately on detecting a problem, or continue in a degraded but safe mode — a choice that depends entirely on which outcome is worse.
Failure Thinking
Making "what happens when this fails?" a standing question applied to every component and every dependency in a design.
Fan-Out
One incoming request causing many outgoing ones, which multiplies both load and tail latency.
Fault Tolerance
Continuing to operate correctly despite the failure of some components, by design rather than by luck.
Idempotency
The property that performing an operation many times has the same effect as performing it once.
Idempotency Key
A client-generated unique value sent with a request so the server can recognise a retry and return the original result instead of acting twice.
Mass Assignment
A vulnerability where a request body is bound directly to an internal object, allowing a caller to set fields the API never intended to expose.
OWASP Top Ten
A periodically updated consensus list of the most critical web application security risks, useful as a design-review checklist.
Pivot Transaction
The step in a saga after which the transaction can no longer be cancelled — everything before it is compensatable, everything after it is retriable until it succeeds.
Presenting to Engineers
Presenting a design at the level of mechanism, including the alternatives rejected and the parts you are still unsure about.
RTO and RPO
How long recovery may take (RTO) and how much data may be lost (RPO), the two numbers that determine the cost of a resilience design.
Regulatory Constraint
A legal requirement that removes design options — and one that must be established early, because it is not negotiable and is expensive to retrofit.
SOLID
Five object-oriented design principles — single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion.
Separation of Concerns
Organising a system so each part addresses one concern, and a change to that concern touches one part.
Solution Architecture
The design of a specific system that satisfies a specific business problem under a specific set of constraints.
Spotify's Squad Model and Its Retrospective
The widely-copied Spotify model of squads, tribes, chapters and guilds was a snapshot that did not work as documented even at Spotify — a caution about importing organisational design.
Stripe's API Versioning
Stripe pins each account to the API version current when it integrated and transforms requests and responses between versions internally, so integrations never break and the core …
Technical Proposal
A written argument for a course of action, circulated for review before the work starts, structured so that disagreement surfaces early and cheaply.
Threat Modelling
A structured exercise that identifies what can go wrong with a design, before it is built, by walking the system's trust boundaries.
Design the network layout for a three-tier application in one cloud region. What are the decisions you cannot easily change later?
What the interviewer is testing Whether you know which network decisions are cheap and which are effectively permanent. This is a knowledge question with a clea
A design review presents a new event-driven platform. What cost questions do you ask before approving it?
What the interviewer is testing Whether cost is part of your architecture review or an afterthought handled by finance later, and whether you know the specific
A product catalogue page does 40,000 reads per second against a database that can serve 5,000. Walk me through the caching design, including what happens at 3 AM when the cache is empty.
What the interviewer is testing Whether you can design a cache including its failure modes, rather than saying "put Redis in front of it". The base design Cache
A team shows you a design with eight services. Without knowing the domain, what questions tell you whether the boundaries are right?
What the interviewer is testing Whether you can evaluate a structure from its properties rather than needing to be a domain expert in every system you review. T
An estate has database passwords in environment variables across 200 services. Design the migration to a secrets manager.
Sequence it by risk, not by convenience Phase 0 — stop the bleeding. Secret scanning in CI and on the existing repositories, blocking new commits containing cre
Classify DynamoDB, Spanner and Cassandra under PACELC, and say which half of the classification you would actually design around.
The classifications Store Partition Else Why DynamoDB (default reads) PA EL Serves from any replica; eventually consistent reads avoid a quorum round trip Cassa
Design a URL shortener handling 100 million new links per month and 10 billion redirects. Where is the real difficulty?
What the interviewer is testing The classic warm up. What is being assessed is not whether you can shorten a URL — it is whether you do capacity arithmetic befo
Design an order submission API that is safe when the client cannot tell whether its request succeeded. What exactly do you store, and when?
What the interviewer is testing Whether you know that "make it idempotent" is a design with specific failure modes, not a checkbox. The core design The client g
Design the audit logging for a system handling financial transactions. What is logged, where does it go, and what makes it hold up?
What is logged Significant actions only , defined explicitly rather than logging everything — an audit trail nobody can search is not usable evidence: Authentic
Design the timeout configuration for a request that passes through gateway, orders, pricing and inventory. What numbers, and what rule generates them?
The rule that generates the numbers One budget at the edge, decreasing inward, with room for a retry at exactly one layer. Start from what the caller will actua
In a design review, a respected senior engineer proposes an approach you believe is wrong. The room defers to them. How do you handle it?
What the interviewer is testing Whether you can be effective without authority, which is most of the architect's job. It is also testing whether you assume you
Maersk rebuilt roughly 4,000 servers and 45,000 PCs in about ten days after NotPetya in 2017, and recovered its directory only because one data centre had been offline during the attack. What does this say about DR design?
The case, as publicly reported In June 2017 the NotPetya malware — destructive rather than financially motivated — propagated through Maersk's network, encrypti
Placing an order must reserve stock, charge the card and create a shipment across three services. Design it, and justify why not a distributed transaction.
First: question the boundary A transaction spanning three services often means one invariant has been split across three owners. Before designing a protocol, ch
Product wants to add "customers who bought this also bought" using purchase history. What does privacy by design require here?
The first question is lawful basis, not architecture Purchase history was collected to fulfil orders. Using it for recommendations is a new purpose , and purpos
You are reviewing a design for an internal tool with 200 users. It proposes Kubernetes, microservices, Kafka, a service mesh and CQRS. How do you handle the review?
What the interviewer is testing Judgement, and whether you can push back without alienating a team. Anyone can spot over engineering; the question is what you d
You must roll out MFA to 40,000 employees. Security wants hardware keys; the service desk fears the call volume. Design the rollout.
The framing that resolves the argument Not every identity carries the same risk, so not every identity needs the same factor. A uniform mandate is what creates
Your services currently trust anything inside the VPC. A security review says move to zero trust. What changes, and what will it cost you?
What the interviewer is testing Whether "zero trust" is a concrete set of changes to you, or a slogan. What actually changes Workload identity. Every service ge
VPC Design
Address planning, peering and the ranges you can never resize.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
REST Design
Resources, uniform methods, status codes and statelessness.
Secure API Design
Object-level authorisation, input validation and safe error responses.
Architecture Cost Modelling
Pricing a design before building it, at expected and at ten times volume.
Business KPIs
The numbers a design is ultimately judged against.
Business Understanding
Connecting a design to the outcome that pays for it.
Ethics in Architecture
Privacy, accessibility, sustainability and the consequences of a design.
Facilitation
Running a design session that reaches a decision.
FinOps Practice
Inform, optimise, operate — and cost as a design-review criterion.
OWASP Risks
The recurring web and API risk classes, several of which are design flaws.
Regulatory Constraints
Non-negotiable requirements that remove design options entirely.
Requirements to Constraints
Turning stated requirements into the constraints that actually bound a design.
SOLID
Five design principles, two of which scale beyond the class.