Draw a Baseline Diagram with Trust Boundaries and Failure Domains

A candidate’s sketch shows vendor logos connected by arrows, but it cannot answer three evaluator questions: Where does the request travel? Which areas have different trust expectations? What parts can fail together? Let’s replace that sketch with a neutral baseline for the synthetic seasonal storefront.

A trust boundary
separates areas with different exposure or access expectations. It does not, by itself, define authorization. A line between the public internet and the cloud marks an exposed entry point, while a line between the application and data segments indicates that data stores should not accept direct public traffic.

A failure domain
is a group of components that can become unavailable due to a shared failure. A diagram should show failure domains separately so we can explain how the workload continues when one domain is lost.

Diagram labels that support an interview narration

Start with only the labels needed to defend the baseline. Include the customer actor, the web or mobile client, the entry tier, the web and application tier, data-store roles, and visible boundary lines. Arrows should represent request flow, not every possible management connection.

Keep authorization separate from topology. The diagram can show that the application segment is the only path toward the data segment, but it does not prove which identities may make a request. We will keep service selection and detailed network routing out of this baseline because neither helps answer the first design question.

For the seasonal storefront, the request path begins at a customer browser. It reaches an edge or ingress layer, continues to stateless application instances, and then reaches only the cache or database role required to serve the request. Static product images and other static files can take a separate path through object storage because application instances do not need to generate or retain them.

Storefront baseline topology

Draw the client on the left. Place the public-internet boundary after it, then put the cloud boundary around the rest of the workload. Inside that cloud boundary, place an ingress and load-balancing role before the application segment. The application tier receives dynamic storefront requests and remains stateless, so another instance can handle a later request without depending on local session data.

Place a cache beside the application tier because seasonal traffic can repeatedly request product and catalog data. Put the database role behind the data-segment boundary. The application tier may query the cache and database, while the ingress layer does not directly reach either data store. Place static assets in an object-storage role reached through the entry path, not through the application tier for every image request.

Show two failure domains, such as two Availability Zones, within one Region. Draw application capacity in each domain and show the request entry role distributing traffic toward both. The cache and database remain logical roles in this baseline. Their exact replication and failover mechanics require validation before we claim resilience details.

Inspect the request path, the two boundary types, and the failure domains before narrating the design.

A one-minute narration

Let’s narrate from left to right. “Customers access the seasonal storefront over the public internet. The ingress layer accepts web traffic and sends dynamic requests to stateless application capacity across two failure domains. The application tier reads frequently requested catalog data from a cache and uses the database for durable transactional data. Static assets follow the object-storage path. A boundary separates public access from cloud resources, and another separates the application segment from the data segment.”

That narration makes assumptions visible. It assumes one Region is sufficient for the initial latency requirement. It assumes application instances do not retain customer session state locally. It also shows that loss of one failure domain should not remove all application capacity, while avoiding unsupported claims about a specific provider’s implementation.

Trade-offs, risks, and next checks

Close with a deliberate trade-off rather than presenting the diagram as complete. “We choose a single-Region baseline with two failure domains because it keeps the first design simple and improves availability within the Region. We accept that users far from the Region may see higher latency and that a regional failure remains an open risk.”

Then name the risks that could change the design:

• Seasonal traffic may exceed the estimated peak.

• Cache behavior may not reduce database demand enough.

• Data classification may require stronger isolation or retention controls.

• Database recovery objectives may exceed what the initial baseline can provide.

• A regional outage may be unacceptable for the business.

Finish with checks that can produce evidence. Confirm load-test inputs, including expected peak requests, read-to-write ratio, payload sizes, and acceptable latency. Confirm data classification with the responsible business and security stakeholders. Run a controlled failure-domain test to verify that requests continue when application capacity in one domain is unavailable.

Avoid two weak diagram habits. Provider logos do not communicate trust or failure boundaries, so use labeled boxes and lines first. Do not add queues, search clusters, extra regions, or specialized services unless a requirement justifies them and we can explain their failure behavior.

Use the same close each time: trade-off, risks, next checks. Choose the simpler baseline when stated requirements support it, then accept the residual risk that unvalidated load, data requirements, or regional availability needs may force the architecture to change.