Lyft Solutions Architect Interview Preparation Guide - Junior Level

Situation / intent: Design a versioned public REST API for creating orders used by two client types (mobile customers, partner carriers), with webhooks for async status updates and guaranteed idempotent creation.

API surface (concise request / response)

POST /v1/orders
Headers:

• Authorization: Bearer <token>
• X-Client-Type: customer|carrier
• Idempotency-Key: <UUID> // required for create

Request JSON:
{
"client_id": "string", // assigned to caller
"order_type": "shipment|pickup",
"items": [{ "sku": "string", "qty": int }],
"destination": { "address": "...", "lat": float, "lng": float },
"pickup_window": { "start": ISO8601, "end": ISO8601 },
"callback_url": "https://client.example/webhook" // optional per-client webhook override
}

Response 201 Created:
{
"order_id": "uuid",
"status": "created|pending_validation",
"created_at": ISO8601,
"links": { "self": "/v1/orders/{order_id}", "status_webhook": "..."}
}

Async updates: system sends POST to registered callback_url or pre-registered webhook endpoint:
Webhook body:
{
"order_id": "uuid",
"status": "accepted|in_transit|delivered|failed",
"updated_at": ISO8601,
"metadata": {}
}
Header: X-Signature: HMAC-SHA256 of body using customer-specific secret.

Design choices

• Versioning: URI versioning (/v1/) for clear, cache-friendly upgrade path; supports breaking changes, easy routing; use semantic major version increments. Support content negotiation (Accept: application/vnd.myapi.v1+json) if needed later.
• Authentication: OAuth2 Bearer tokens (Client Credentials for carriers, Authorization Code for mobile customers). Token scopes restrict actions (orders:create, orders:read, webhooks:manage). Use per-client webhook secret for webhook signing.
• Idempotency: Idempotency-Key header (UUID) required on create requests. Server stores (Idempotency-Key, client_id) -> response for a TTL (e.g., 24h). On retry with same key, return same 201/response or appropriate error if conflict. Also include Idempotency-Key in logs and in webhook metadata for correlation.
• Client differentiation: X-Client-Type header + token scope to enforce different validation/business rules (e.g., carriers can set driver info).
• Security: Rate limit per client, validate callback_url domain against allowlist for partners, HSTS/TLS required.

Edge cases & notes

• Reject missing/invalid Idempotency-Key with 400.
• If idempotency record expired, treat new create (return 201 new order).
• Webhook delivery: retry policy with exponential backoff and dead-letter queue; expose webhook delivery status in order resource for debugging.
  This design balances simplicity for clients, strong idempotency guarantees, and secure webhook callbacks while allowing future versioning and extensions.

Linearizability, sequential, causal, and eventual consistency are four progressively weaker guarantees about the order in which operations on shared data appear to happen. Linearizability makes every operation look instantaneous and match real, wall-clock time. Sequential consistency drops the real-time requirement but still gives every observer the same single global order. Causal consistency only orders operations that are actually cause-and-effect related, letting unrelated operations be seen in different orders on different replicas. Eventual consistency drops ordering guarantees almost entirely and only promises that replicas converge once writes stop. Each weaker model permits more anomalies than the one above it.

Worked example: why causal consistency prevents an anomaly eventual consistency allows

Consider a social feed. Two events happen, in this order, involving the same user's friend:

1. Event P: a user publishes Post P.
2. Event C: after reading Post P, the user's friend writes Comment C, which references Post P.

Because the friend read P before writing C, C causally depends on P: P happened-before C.

• Under causal consistency, any replica that delivers C to a reader must already have delivered P to that same reader. There is no way for a client to see Comment C replying to Post P without also being able to see Post P: the system enforces the happened-before relationship on delivery.
• Under eventual consistency alone, P and C might replicate along different paths (different shards, different network routes) with no ordering guarantee between them. A reader on a lagging replica could receive C's replication packet before P's, and briefly render a comment that references a post the reader's own client cannot find yet, an orphaned reply. That is exactly the anomaly eventual consistency does not rule out and causal consistency does.

Because eventual consistency only promises the base table converges, a secondary index or materialized view (for example, a 'comments by post' index used to render the feed) can lag the base write for an unbounded window: the index might still return zero comments for Post P for some time after Comment C has already durably landed on a majority of the base replicas, since building the index from the base table's write stream is itself an eventually-consistent process, not an atomic one.

Trade-offs & pitfalls

• Common wrong turn: treating eventual consistency as one well-defined guarantee. It is really the absence of a guarantee during the convergence window, so two systems both labeled eventually consistent can behave very differently depending on how long that window typically is, and what session-level guarantees (read-your-writes, monotonic reads) are layered on top.
• Sequential consistency is rarely offered as a named product feature; it mostly shows up as an accidental byproduct of serving reads from any replica of a system that internally agrees on a single write order, without adding a real-time freshness check on the read path.
• Causal consistency requires tracking dependencies, commonly via vector clocks or similar metadata, which costs storage and complicates garbage collection, the same trade-off logical clocks introduce elsewhere in this material.
• Senior answers name the actual anomaly each model still allows, not just that it is looser. An answer that only says eventual is looser than causal, without naming a concrete permitted anomaly, is incomplete.

Situation: A customer needs to send notifications to millions of devices across different segments (user-selected topics, ad-hoc queries, and custom audiences). Below is a comparison of three fan-out strategies and guidance for selecting/combining them.

Per-recipient fan-out (query-per-send)

• How: For each notification, query user store and push individually (or via per-device queue).
• Pros: Maximum flexibility (personalization, precise targeting), immediate consistency.
• Cons: Very high compute and push API cost at scale; higher latency due to millions of lookups and push calls; complex rate-limiting and backpressure handling.
• Use when: Highly personalized messages or small audiences (<100k) where precision matters.

Precomputed audience batching (topics/groups)

• How: Maintain precomputed groups (topics) in your system; send one message per group to an internal queue or provider topic.
• Pros: Lower fan-out work at send time, predictable cost, faster delivery for large groups, simpler retries.
• Cons: Staleness risk (must update groups on membership change), extra complexity to maintain membership pipelines, less granular personalization.
• Use when: Stable segments (e.g., “premium users”, “NYC commuters”), frequent repeated broadcasts.

Provider-topic-based delivery (push-provider topics)

• How: Use provider-managed topics (e.g., FCM topics, SNS topics) and let provider fan-out to devices.
• Pros: Offloads scale and delivery cost to provider, low sender-side latency and compute, simple implementation.
• Cons: Limited membership control and visibility, provider-specific limits and semantics, harder to enforce complex business rules and personalization.
• Use when: Very large, loose-segment broadcasts and where provider features meet requirements.

Trade-offs summary (millions of devices)

• Latency: Provider-topics ≈ fastest (minimal server work) > precomputed topics > per-recipient (slowest).
• Cost: Provider-topics lowest sender CPU/network cost; per-recipient highest; precomputed medium (storage+update pipelines).
• Complexity: Per-recipient most engineering work (scaling, retries); provider-topics simplest; precomputed requires membership sync logic.

Recommendations

• Hybrid: Use provider-topics for broad broadcasts, precomputed topics for common business segments, and per-recipient fan-out for personalization or transactional messages.
• Operational controls: add rate limiting, batching, backoff, idempotency keys, monitoring (delivery metrics, membership freshness), and cost caps.
• Consistency & correctness: implement real-time or near-real-time membership updates (streaming updates or event-driven sync), and support fallback (e.g., split into smaller batches) to handle provider limits.
• Compliance & opt-out: ensure opt-out propagation across all membership stores and provider topics.

This approach balances latency, cost, and operational complexity while allowing targeted personalization when required.

Situation / goal: The client must operate in EU and US markets but faces conflicting data residency and processing rules (e.g., GDPR restrictions, Schrems concerns, and US lawful access). I’ll define a requirements capture and governance approach that records jurisdiction-specific obligations, resolves conflicts, preserves traceability, and enables multi-region deployments with baseline controls plus federated change control per legal regime.

Approach (high-level):

1. Requirements intake: Use a jurisdiction-aware template capturing: data element classification (personal, sensitive, pseudonymized), purpose, legal basis, residency, retention, allowed transfers, processors/sub-processors, logging/audit, and breach notification timelines.
2. Mapping & matrix: Build a Jurisdiction Requirements Matrix (JRM) that maps each data element to obligations per jurisdiction and flags conflicts automatically (e.g., “cannot transfer outside EU” vs “must store in US”).
3. Conflict resolution workflow: For flagged conflicts, apply ordered rules: prioritize binding legal obligations -> apply mitigations (localization, pseudonymization, encryption, split processing, legal contracts) -> escalate unresolved legal vs business tradeoffs to a decision board (Legal, Privacy Officer, Product, Architecture).
4. Architecture baselines: Define per-region baseline controls (EU Baseline: data stays in EU, encryption-at-rest with EU KMS, pseudonymization, DPIAs; US Baseline: US-resident storage, access controls, SIEM forwarding rules). Baselines are versioned artifacts in the architecture repository.
5. Traceability: Use a requirements management tool (Jira + Confluence OR specialized RM tool) to link: requirement → data element → design artifact → deployment config → evidence (audit logs, DPIA, contracts). Each link records jurisdiction tag and rationale.
6. Deployment model: Multi-region with data plane locality and global control plane where permitted. Techniques: regional storage buckets, regional KMS keys, service-level feature flags to enforce local processing, API gateways that route by jurisdiction, and tokenization/proxy services for cross-border needs.
7. Federated change control: Implement a two-tier change process: Global Architecture Board approves cross-cutting changes; Regional Legal/Privacy delegates handle jurisdictional scope. Changes require automated impact analysis from the JRM (showing affected data elements/jurisdictions) and gating criteria (e.g., legal sign-off for policy-affecting changes). Maintain immutable audit trail of approvals.
8. Controls & evidence: Automate policy enforcement with infrastructure as code, policy-as-code (OPA/Gatekeeper), CI/CD gates that validate region constraints, and continuous compliance scans. Produce artifacts (DPIAs, SCCs, BCR-like summaries, contractual clauses) per jurisdiction.
   Example conflict and resolution: If a product requires user profiling in US but EU users’ personal data cannot be transferred, options: (a) Keep EU data in EU and run profiling on EU regional cluster; (b) export only pseudonymized aggregates via one-way hashes + EU legal assessment; (c) obtain explicit consent with documented opt-in flows. Use the JRM to quantify control effectiveness and present trade-offs to the decision board.

Why this works: It combines automated detection, clear baselines, traceable links from requirement to evidence, and a federated governance model that balances central consistency with regional legal expertise—enabling compliant, scalable multi-region deployments.

Direct answer
A traceability matrix exists to make sure every technical requirement can be traced back to a real business reason, and every business objective has concrete, owned work behind it, so nothing gets built without a purpose and nothing important gets silently dropped.

Structured elaboration
The matrix works because each row forces the same discipline: a business objective that can't be mapped to a measurable technical requirement is too vague to build against, and a technical requirement with no objective behind it is a candidate for removal.

Worked example
For the "enable ad-hoc queries" row, the acceptance criterion is deliberately specific (90% success rate, one-month measurement window) rather than "analysts can query the data," because the vague version can't distinguish a genuinely successful rollout from one where analysts are still routing most requests through engineering, which is the actual failure mode this objective exists to prevent.

Trade-offs and pitfalls
The most common failure is building the matrix once at project kickoff and never revisiting it, so it becomes a stale artifact that doesn't reflect what was actually built by the time of a later incident or audit. The second common failure is making the metric column vague ("improved query performance") instead of a specific, measured number with a defined measurement window, which makes the row impossible to verify as done or not done.

Recommendation summary: choose Amazon Aurora for a single-region OLTP deployment needing 5,000 writes/sec and <50ms strong-consistency on the primary; choose CockroachDB if you require geographically-distributed strong consistency (multi-region) and are willing to accept slightly higher cross-region latency and more complex ops.

Comparison and trade-offs:

1. Vertically scaled Postgres (single node/RDS)

• Latency & writes: A beefy instance (m5/r5 with NVMe) can easily hit 5k writes/sec with <50ms median latency for single-region traffic.
• Consistency: Strong (single-writer).
• Cross-region replication: Async (logical/physical replication) → eventual across regions, so not strongly consistent globally.
• Operational overhead: High for HA, failover, backups, WAL shipping, scaling writes (downtime to scale), single point of failure risk unless you build complex clustering.
• When to pick: Simple, predictable single-region workloads and you accept manual HA complexity.

2. Amazon Aurora (Postgres-compatible)

• Latency & writes: Managed storage and writer/reader separation sustain high write throughput; sub-50ms latency achievable in single region.
• Consistency: Strong on the primary writer. Readers may be slightly behind but Aurora provides fast failover and low replication lag.
• Cross-region replication: Global DB features provide fast read-only replicas in other regions but replication is effectively asynchronous → not global strong consistency.
• Operational overhead: Low (managed), automated scaling, backups, failover, monitoring.
• When to pick: Managed single-region primary with high throughput and low ops burden.

3. CockroachDB

• Latency & writes: Designed for distributed OLTP with serializable transactions. For single-region deployments it matches Postgres-level latency. For multi-region clusters, writes that need cross-region consensus (Raft) will incur added RTTs and may exceed <50ms depending on region distances.
• Consistency: Strong (serializable) across nodes/regions.
• Cross-region replication: First-class — geo-partitioning and survivable multi-region design with strong consistency.
• Operational overhead: Medium — it's self-managing for many concerns but requires understanding of topology, locality, and cost for replicas; ops for upgrades and tuning still important.
• When to pick: Global, strongly-consistent applications where correctness across regions matters more than absolute minimal latency.

4. Cassandra

• Latency & writes: Very high write throughput and low local latency, but writes are eventually consistent by default (tunable via consistency levels).
• Consistency: Tunable; achieving strong consistency requires QUORUM/ALL reads+writes which increases latency and removes many benefits of Cassandra.
• Cross-region replication: Designed for geo-distribution and availability, but consistency guarantees are weaker unless tuned (with latency trade-offs).
• Operational overhead: High — complex to tune for consistency and repair, SStable management, and ops for scaling.
• When to pick: High write-volume, highly-available, eventual-consistency use cases (time-series, logging), not ideal for strict strong-consistency OLTP.

Decision logic (how I’d advise a client):

• If requirement = strict strong consistency but only single region and <50ms: Aurora (managed) or a vertically-scaled Postgres HA cluster if you need full control. Aurora reduces ops and scales writes better than single Postgres.
• If requirement = strong consistency across multiple regions (global correctness), choose CockroachDB and design region-aware placement; accept that cross-region writes may exceed 50ms depending on RTT — mitigate by routing writes to a local region or sharding by geo.
• If ultra-low latency global writes with availability > consistency: consider Cassandra but only after accepting application-level eventual-consistency.

Other considerations:

• Network RTT dominates multi-region latency; test with realistic topology.
• Cost: Managed services (Aurora) reduce ops but can be pricier; CockroachDB multi-region cost includes storage and cross-region egress.
• Failure/failover: Aurora has fast managed failover; with Postgres you must design for HA; CockroachDB tolerates node/regional failures if topology is correct.
• Operational maturity: Aurora/Postgres have larger ecosystem and talent pool; CockroachDB growing but fewer operators; Cassandra requires experienced ops team.

Example recommendation statement you can present to stakeholders:

• “For a 5k writes/sec, low-latency (<50ms) OLTP workload confined to one region, select Amazon Aurora for lowest operational overhead and predictable latency. If business requires global strong consistency, choose CockroachDB and design for regional locality to keep latency acceptable; otherwise Cassandra is not recommended due to eventual consistency trade-offs unless you can accept higher latencies when enforcing stronger consistency levels.”

Approach

Two distinct deliverables here: a safe process for resizing based on 3 months of real telemetry, and a separate evaluation of where spot/preemptible instances can save money without breaking any SLA (service level agreement, a contractual latency/availability promise).

Step-by-step safe right-sizing process

1. Aggregate the 3 months of utilization (CPU, memory, IOPS, input/output operations per second, network) at percentile granularity, segmented by day-of-week and time-of-day, since 3 months is long enough to catch monthly or quarterly patterns a shorter window would miss.
2. Classify by variance, not just average. A steadily-60%-utilized instance and a bursty instance averaging 10% but peaking at 90% need very different sizing treatment even though their averages might look similar.
3. Downsize steady-state resources to the smallest size that still covers the observed p99 (99th percentile) plus a margin.
4. Flag near-idle resources for a bigger move than downsizing, scheduling them off during off-hours, or decommissioning them, rather than just picking a smaller instance size.
5. Stage the rollout: canary on a subset first, monitor for a full week to catch the weekly cycle, then roll out fleet-wide, with the previous instance size recorded so a revert is a single step.
6. Re-baseline telemetry after the change lands, to confirm the new size still has adequate headroom as traffic naturally grows.

Evaluating spot/preemptible instances without violating SLAs

Good fits: workloads that are stateless or checkpoint-able (so a reclaimed instance doesn't lose unrecoverable work), horizontally scalable across many instances (so losing one is a small fractional capacity hit, not an outage), and not on a latency-critical synchronous request path, batch workers, CI runners, background jobs.

Poor fits, unless paired with a fallback: the steady baseline of a request-serving fleet under a tight SLA, primary database instances, anything stateful without fast failover.

To use spot safely where it does fit: size a reserved or on-demand baseline that alone can meet the SLA even if all spot capacity vanished at once (the honest worst-case check); spread spot capacity across multiple instance types and availability zones to reduce correlated reclamation risk; and handle the typical short reclamation notice (often around 2 minutes) by draining in-flight connections and deregistering from the load balancer before the instance is actually taken, rather than dropping requests abruptly.

The two deliverables connect: the same 3-month telemetry that tells you a resource is safe to downsize is also what tells you whether its load is steady enough to trust with spot, or too latency-critical to risk it.

Direct answer

Decide per field with a simple test: what does a user or the business lose if this field is read stale for a few seconds, and does that loss involve authorization, money, or identity? Email, password, and account status gate who can act as whom, so they get a linearizable (single, globally agreed order) read/write path even at a latency cost. Display name and avatar are cosmetic: a stale value for a few seconds costs nothing but a visual blip, so they get eventual, region-local, low-latency writes and reads. Defending the split means showing what making everything strong actually costs on the read path, not just asserting that it is safer.

Structured elaboration

Per-field decision table

Mechanism

This paragraph is implementation detail, useful to know by name but not required to follow the field-by-field argument made above it. Two logical stores per user: a small, strongly-consistent store (consensus-replicated, for example a Raft-based database, where Raft is an algorithm that gets a cluster of replicas to agree on the same order of writes, or a globally-consistent database) for the identity-critical fields, and a multi-region, eventually-consistent store (Dynamo-style or similar) for everything else. Reads compose a single user object from both stores, so only the strong-store portion pays the cross-region latency cost. Read-after-write for the strong fields comes from routing that specific read to the writer's region or the current leader; monotonic reads (once a client has seen a value, a later read never shows it an older one) for the weak fields come from a session token, not from the strong store.

Extending the framework: billing correctness without going fully strong

Billing state is the case that tempts people into "just make everything strong." Resist it: instead of a synchronous global commit for every billing event, use compensating transactions, an idempotent charge (safe to run the same charge request twice, say after a retry, without actually billing the customer twice) plus a defined reversal or refund path if a downstream step (fraud check, inventory hold) fails after the charge already happened. This gets you correctness (the ledger is right once reconciliation finishes) without paying the linearizable-everything latency tax on a field written far less often than it is read.

Defending the split with a number, not an opinion

The strongest defense against "why not just make it all strong" is quantifying what "all strong" costs on the read path, since profile reads vastly outnumber profile writes.

Worked example

Assume a region-local cache read costs 5 ms, and a linearizable read from the strong store (contacting a majority of replicas across 3 regions, with an illustrative one-way inter-region round-trip time (RTT) of 100 ms) costs roughly two one-way trips:

If, say, 95% of profile reads only ever touch display-name or avatar fields (illustrative traffic mix, would come from real access logs), forcing all of them through the strong store means 95% of read traffic pays a 40x latency tax for a guarantee only the remaining 5% of fields ever needed. That is the number to put in front of someone asking why you didn't make everything strongly consistent.

Now the revenue-risk quantification (the second absorbed angle): the case for still investing in correctness on the billing fields, even though they don't get the fully linearizable treatment either.

Ten thousand dollars a day of exposure (illustrative; in practice pulled from real incident and error-rate data) is what justifies spending engineering time on compensating transactions for billing.

Trade-offs & pitfalls

• The strong store becomes a small, high-value target: shard it narrowly (identity fields only) so its lower throughput ceiling never becomes the bottleneck.
• Session tokens that carry the last-seen strong-store commit are what give read-your-own-writes on the critical fields without every read hitting the leader; skipping this is a common miss that reintroduces stale-password bugs.
• Pitfall: treating "eventual consistency" as a synonym for "no correctness work needed." The weak store still needs a conflict-resolution rule (last-writer-wins or a merge function), or two concurrent display-name edits silently lose one.
• Pitfall: treating billing as either fully strong or fully eventual instead of reaching for the third option, compensating transactions, which is usually the right cost and correctness balance for money-adjacent but not identity-adjacent fields.

No single number proves burnout. Track three families of signals together: raw load (pages per person per week), response burden (after-hours percentage, time-to-resolve), and human signals (fatigue self-reports, PTO usage), and watch for the same people repeatedly crossing thresholds across categories, not just one bad week.

What to track

Worked example: reading a four-week rotation block

Suppose the primary on-call received a combined 88 pages across the last 4-week rotation block (one week per engineer).

Against the roughly-under-10/week guideline, 22 pages/week is more than double, a sustainability flag on its own. If 39 of those 88 pages fired between 20:00 and 08:00:

well above the roughly-25% guideline, corroborating that this isn't just a high-volume rotation, it's specifically disrupting sleep.

Trade-offs and pitfalls

These metrics can be gamed by suppressing alerts; pair volume metrics with an independent audit (a sampled review of closed incidents) so under-alerting doesn't masquerade as improvement. Self-reported fatigue data is noisy and subject to survey fatigue itself; treat it as a leading indicator alongside hard metrics, not as the sole trigger for action. A single bad week (one major outage) will spike every metric at once; look for a sustained pattern across at least a full rotation cycle before concluding the rotation itself, rather than the incident, is the problem.

Direct answer

Start with the component diagram. It establishes what pieces exist and who owns each one, before anything about behavior or payloads makes sense; architects can't reason about "what happens when" until they know "what's here."

Structured elaboration

1. Component diagram (what exists). Purpose: boundaries and ownership. Show: application services, cache cluster nodes, the source-of-truth database, an invalidation service, and a message broker. Leave off: exact protocol, message schema, and timing, those belong later.

2. Sequence diagram (what happens, in order). Purpose: the actual interaction for one invalidation event. Show: a write to the database, the database acknowledging it, an event published to the invalidation service, that service publishing an evict message on the broker, the broker fanning out to cache nodes, and one failure path (broker unavailable: what serves stale data, and for how long). Leave off: byte-level payload detail and retention settings, that's the next diagram's job.

3. Data-flow diagram (what exactly, and how stale). Purpose: payloads and guarantees. Show: the invalidation message's schema (key, version, timestamp), time-to-live, message size, and the one metric architects will actually watch, invalidation latency or staleness window. Leave off: anything already covered by the component-level framing.

Why this order helps comprehension: each diagram answers the question the previous one raised. Component diagram: "what is the invalidation service." Sequence diagram: "how does it know to fire." Data-flow diagram: "how stale can a read get before this evicts it." Reversing the order, starting with the sequence diagram, forces you to define every box mid-sentence instead of pointing at one the audience has already seen.

Worked example

The component diagram you'd draw first:

flowchart LR
    App[Application] -->|write| DB[(Database)]
    App -->|read| Cache[(Cache Cluster)]
    DB -->|change event| Invalidator[Invalidation Service]
    Invalidator -->|publish evict msg| Broker[[Message Broker]]
    Broker -->|fan out| Cache
    Cache -->|miss, reload| DB

Narrated: "The application writes to the database. That write triggers a change event to the invalidation service, which publishes an evict message on the broker. The broker fans that message out to every cache node, and the next read that misses reloads from the database."

Translating the core idea for the architects: the jargon term is "cache coherence." Plain version: "keeping the cache from serving an answer that's gone stale since the database changed." Analogy: it's like a library's card catalog. When a book gets re-shelved, someone has to walk over and update the card, or the next person who checks the card gets sent to the wrong shelf. Where the analogy breaks: no single librarian updates every card at once across a building, the fan-out to many cache nodes in parallel, possibly across regions, is exactly what makes this hard in practice, and that's the detail worth naming once the audience has the basic picture.

Trade-offs & pitfalls

The common wrong turn is leading with the sequence diagram because it feels more "technical," which forces you to define the invalidation service, the broker, and the cache cluster mid-sentence instead of pointing at boxes the audience already recognizes. A second pitfall: putting the failure path (broker down) in the component diagram instead of the sequence diagram, error paths are behavior over time and belong where the audience is already reasoning about timing. A third: overloading the data-flow diagram with architectural detail that duplicates the first diagram instead of adding new information (payload size, TTL, staleness), which makes the customer conversation feel repetitive rather than cumulative.