Senior Follow-Up Playbook

The eight reusable lenses

1. Invariant and authority

Ask:

• Which fact is authoritative?
• Which service or partition is allowed to change it?
• What must be atomic?
• Which copies are projections, caches, indexes, or replicas?
• How is a contradiction detected and repaired?

A design without authority often hides accidental dual writes. Name one place where a business decision becomes committed. Derived systems may be highly available and stale, but they should not silently become a second source of truth.

2. Ambiguous outcomes and idempotency

Inject a timeout after every write boundary:

• after the server receives the request;
• after the database commits;
• after the event publishes;
• after the external side effect succeeds;
• before the acknowledgment reaches the caller.

For each, decide whether retry is safe. Carry a stable operation/idempotency ID, persist prior result or state, use unique constraints/conditional transitions, and expose a status lookup for long or ambiguous operations. “The client retries” is incomplete until the duplicate business effect is prevented.

3. Skew, hotspots, and noisy neighbors

Replace average input with:

• one tenant at 20% of traffic;
• one key at 100× normal popularity;
• one object at global viral scale;
• one partition containing the largest customer;
• one expensive query that bypasses cache;
• one consumer whose downstream call is 50× slower.

Then inspect key choice, caches, partitioning, quotas, isolation, fairness, adaptive movement, and dedicated capacity. Senior capacity planning reports per-tenant and per-partition distributions, not only fleet utilization.

4. Partial failure and stale control planes

Do not make nodes fail cleanly. Isolate them while they continue running. Delay messages. Freeze a control plane while data planes serve. Let two components hold different routing/configuration epochs.

Ask:

• Can two leaders or owners accept work?
• How are terms, leases, or fencing tokens validated?
• Do stale clients redirect, reject, or corrupt?
• What degraded operation remains safe?
• What happens when the partition heals?

5. Overload and work conservation

A queue, cache, retry, or autoscaler can delay symptoms but cannot defeat sustained offered load above capacity. Ask:

• Where is the first bounded queue?
• Which work is admitted, prioritized, delayed, or shed?
• Do deadlines make queued work obsolete?
• Which retry layer owns the budget?
• Does adding workers overload the database or third party?
• How long does the backlog take to drain at net capacity?

Protect recovery and control traffic from bulk work. Prefer stable degradation over synchronized collapse.

6. Migration and reversibility

Assume the system already exists and carries critical data. A senior plan includes:

1. Compatible schema/contract expansion.
2. New code that can read old and new forms.
3. Bounded snapshot/backfill plus ordered changes.
4. Validation and shadow/dual reads.
5. Small canary cutover with observable success criteria.
6. Ownership/fencing switch.
7. Rollback before destructive cleanup.
8. Delayed contract/removal and cost cleanup.

Ask how much temporary storage, network, and write amplification the migration needs and whether it can pause safely.

7. Operability and proof

For every asynchronous or replicated path, define a completeness proof:

• source versus projection version/count/checksum;
• oldest event/outbox/queue age;
• replica log/applied position;
• cache data age and invalidation lag;
• object inventory versus metadata references;
• batch manifest and expected partitions;
• deletion workflow status across derivatives.

8. Organization and economics

At staff level, ask:

• Which team owns the boundary and on-call?
• Is this a shared platform or product-specific component?
• How are schemas, SLOs, quotas, and breaking changes governed?
• What is the dominant cost unit and who pays it?
• What skills and tooling are required?
• How can teams migrate incrementally rather than through mandate?
• What is the exit strategy if the chosen technology no longer fits?

Failure inject deck

Pick two during a mock:

Inject	What a strong answer explores
Primary times out after commit	Idempotency, status lookup, retry semantics, duplicate external effects
Zone becomes isolated but nodes remain alive	Quorum/leader authority, fencing, routing, stale reads, healing
Cache cluster restarts	Origin protection, warmup, admission, hot keys, degraded response
Queue backlog grows for six hours	Net drain, expiry/priority, downstream limits, DLQ/retry storm
Largest tenant grows 50×	Key skew, isolation, directory placement, quotas, migration
DNS record changes during incident	TTL/negative cache, old endpoints, connection reuse, rollback
One dependency p99 rises from 50 ms to 5 s	Deadline propagation, concurrency/queue memory, circuit breaker, fallback
Replica is days behind	Reseed versus catch-up, freshness routing, recovery bandwidth
Schema deploy must support two-year-old clients	Additive contract, defaults, feature negotiation, deprecation telemetry
Privacy deletion arrives after data was indexed and archived	Immediate access denial, derivatives, versions, legal hold, evidence
New shard map reaches half the clients	Epoch validation, redirect bounds, old/new owner fencing
Cost must fall 40%	Retention/tiering, cache/egress, overprovisioning, simplification, SLO trade
Metrics say healthy but customers see missing data	Completeness/lag/reconciliation, sampling, trace/operation IDs
A hot key receives 500k QPS	replication/cache, request coalescing, special routing, load shed, semantics
A batch backfill writes older state over live updates	source version, snapshot+delta, conditional apply, cutover manifest

Requirement escalation ladder

Use this ladder to turn a basic design into senior practice.

Stage 1 — Correct single-region service

• One authority and clear API.
• Basic estimate and data model.
• Normal read/write path.

Stage 2 — Production reliability

• Multiple zones, bounded queues, retries/idempotency.
• Backups and restore.
• p99 and saturation metrics.
• Deploy and schema compatibility.

Stage 3 — Large-scale skew

• Large tenants/hot keys.
• Sharding and online movement.
• Cache and async amplification.
• Cost and operational tooling.

Stage 4 — Multi-region and regulatory

• Per-operation consistency and regional write policy.
• Region loss/failback.
• Data residency, privacy deletion, encryption/key control.
• Cross-region bandwidth and dependency readiness.

Stage 5 — Platform and organizational scale

• Self-service APIs and guardrails.
• Tenancy tiers, quotas, SLO classes, cost allocation.
• Migration/adoption, compatibility governance, incident ownership.
• Evidence-driven roadmap and decommissioning.

Trade-off sentence templates

Use these to make reasoning explicit, not mechanical:

“Because [workload/invariant], I prefer [choice] over [alternative]. It spends [latency/cost/complexity/availability] to gain [property]. The design stops fitting when [threshold/evidence], at which point I would [evolution].”

“During [failure], this operation returns [stale/partial/retryable error/tentative success] because preserving [invariant] is more important than [other property]. Recovery uses [replay/repair/merge/fencing], measured by [signal].”

“The authoritative state is [system]. [cache/index/replica] is a derived view with [freshness]. It is rebuilt from [retained source], and completeness is checked by [version/checksum/count].”

Leadership and design-review prompts

Senior interviews may test how a design reaches production, not only its final shape.

Drill 1 Disagreement

• Two teams disagree between a relational database and an event-sourced design. What decision document and experiment would you run?
• Security requires fail-closed authorization; product requires offline availability. How do you classify operations and negotiate?
• A platform team wants one global queue; product teams need custom semantics. Where is the abstraction boundary?

What the interviewer is testing

Strong responses identify stakeholders and non-negotiable invariants, make assumptions observable, compare total lifecycle cost, and create a reversible trial rather than winning by authority.

Drill 2 Legacy migration

• The old system has undocumented consumers and cannot pause writes.
• Data quality is imperfect and schemas differ.
• The business cannot accept a big-bang cutover.

What the interviewer is testing

A strong answer inventories dependencies, defines a canonical model, backfills with version/checkpoint, validates in shadow, moves by cohort/key, preserves rollback, and creates a decommission criterion.

Drill 3 Incident learning

• A retry storm caused a regional outage.
• A lifecycle rule deleted active objects.
• A stale replica authorized a revoked account.

What the interviewer is testing

Go beyond the immediate bug: identify missing guardrails, unsafe defaults, test gaps, observability, ownership, and how to prevent the class of failure across teams.

Drill 4 Cost and simplification

• A five-store architecture is too expensive for a small team.
• A globally coordinated system meets correctness but misses latency.
• A cache saves little because working set exceeds memory.

What the interviewer is testing

Strong candidates remove components, tier requirements, or change the invariant. Seniority is not measured by component count.

Self-coaching questions after every mock

1. What was the first decision-changing requirement I discovered?
2. Did I state the critical invariant before choosing storage?
3. Which number shaped the architecture?
4. Where can a timeout hide success?
5. Which key is hottest and which operation fans out?
6. What happens if a node is isolated rather than dead?
7. How does the system prove a derived copy is complete?
8. What is the online migration and rollback boundary?
9. Which security/privacy risk changes the data path?
10. What would I simplify, and what evidence would trigger the next evolution?