How the interviewer opens it
“Design infrastructure for secure communication between services in a large microservice fleet. Service owners need to control which services communicate and where requests go.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Fleet size
- Traffic and read:write mix
- Route and access rules
- Latency and rollout timing
- Availability and consistency
- Certificates
- Existing infrastructure
- Security boundary
- Durability
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Authenticate service calls and enforce access rules
- Route calls according to service policies
- Distribute policies and certificates across the fleet
- Preserve calls during control outages while credentials remain valid
Usually out of scope
- User authentication
- Public edge traffic
- Application business logic
- Cross-region communication
- A new orchestrator or certificate authority
What interviewers ask about
- Service calls during a control outage
- Local decisions preserve availability. Stale access rules can preserve access that an owner wants to remove. Certificate expiry still limits continued calls.
- Policy changes across the fleet
- A change reaches instances at different times. The system must distinguish durable acceptance, intentional delay, resource acceptance, and actual activation.
- Service identity and certificate changes
- The system must bind credentials to real workloads. Certificate replacement must preserve identity isolation and respect expiry during long connections.
- Request latency and capacity
- Fleet averages hide busy components. CPU limits, connection churn, and queues can consume the two-millisecond budget before the fleet lacks total capacity.
Common mistakes
- The design places the control plane on the request path.
- The design trusts a service name as proof of workload identity.
- The design treats policy delivery as proof of activation.
- The design hides rollout holds inside a five-second latency claim.
- The API accepts updates before a durable cross-zone commit.
- The design promises continued calls after a peer certificate expires.
The bar by level
- Senior (L5/E5)
- Defines identity verification, scoped updates, activation reports, and certificate renewal. Explains cohort clocks and durable acceptance. Budgets request overhead and tests constrained components.
- Staff (L6+/E6+)
- Defines trust and revocation limits. Proves recovery from zone loss without losing accepted changes. Separates rollout delay from activation latency. Quantifies peak capacity and tail latency under churn.