This week decides selection. Architects draw systems. Leaders tell stories. Know your frameworks cold — RESHADED for design, STAR for leadership. One weak answer here ends the process.
Interviewers don't expect a perfect system. They're evaluating: Do you ask the right questions? Do you reason about tradeoffs? Do you know when to use which technology? Do you think about failure? Speak your reasoning aloud — silence is death in system design.
| Decision | Choice | Why — The Architect's Reasoning |
|---|---|---|
| Sync vs Async | Hybrid | Payment initiation sync (user waits for ack). Settlement async via Kafka — decouples latency-sensitive API from slow SWIFT network |
| Idempotency | Redis SETNX + DB constraint | Client sends UUID. Redis lock prevents concurrent duplicates. DB unique constraint is final safety net — two layers of protection |
| Distributed transaction | Saga (Orchestration) | No 2PC in microservices. Orchestrated saga gives visibility, central failure handling, compensating transactions. Temporal or Axon for orchestrator |
| DB choice | Oracle RAC | ACID, Oracle RAC for HA, proven at financial institutions, regulatory compliance. Polyglot: MongoDB for audit (schema-less, append-only) |
| Messaging | Kafka (partitioned by accountId) | Ordering per account. High throughput. Replay for audit. Exactly-once with transactions API. Dead letter queue for failures |
| Caching | Redis (account data, limits, FX rates) | Account metadata: TTL 5min. FX rates: TTL 30s. Payment dedup window: TTL 24h. Never cache balances without invalidation strategy |
The SWIFT network is down for 2 hours. How does your system behave? What does the customer see?
Always say "Let me state my assumptions" before calculating. Interviewers know the numbers are approximate — they're watching whether you can reason logically. Round aggressively: 86,400 seconds/day ≈ 100,000. 1 million bytes ≈ 1MB. Show the formula, then the result.
"Just use a distributed cache to make everything fast." Why might you push back on this?
apiVersion: apps/v1 kind: Deployment metadata: name: payment-service namespace: payments-prod spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 # zero downtime — critical for payments template: spec: containers: - name: payment-service image: registry.wf.com/payment-service:2.4.1 resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" # never exceed — OOMKilled cpu: "1000m" readinessProbe: # traffic only when ready httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 30 periodSeconds: 10 livenessProbe: # restart if deadlocked httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 60 failureThreshold: 3 --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec: minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # scale up at 70% CPU
A deployment broke production payments at 2pm on a Friday. Walk me through your response.
kubectl rollout undo deployment/payment-service. Blue-green: flip load balancer back to blue. Restoration > investigation.Saying "rollback first, debug later" immediately signals experience. Junior engineers want to fix the bug in production. Leads know: restoration is always the priority, understanding is secondary.
| Pillar | What It Answers | Tools | Payment Example |
|---|---|---|---|
| Metrics | Is the system healthy right now? | Prometheus, Grafana, Micrometer, Datadog | Payment TPS, success rate, P99 latency, Kafka lag, DB pool utilisation |
| Logs | What happened for a specific request? | ELK Stack, Splunk, Loki, Fluentd | Structured JSON logs with traceId, paymentId, accountId, correlationId in MDC |
| Traces | Where did latency come from? | Zipkin, Jaeger, Datadog APM, OpenTelemetry | Trace a single payment across API Gateway → Payment Service → DB → Kafka → Settlement |
| Term | Definition | Payment Example |
|---|---|---|
| SLI (Service Level Indicator) | The actual metric being measured | Payment API success rate = successful_requests / total_requests |
| SLO (Service Level Objective) | The target you set internally | Payment success rate ≥ 99.95% over rolling 30 days |
| SLA (Service Level Agreement) | The contractual commitment to customers | 99.9% payment availability — breach triggers financial penalty |
| Error Budget | Allowed downtime = 100% − SLO | 99.95% SLO = 0.05% error budget = 21.9 min/month downtime allowed |
When the error budget runs out, you stop new feature releases and focus only on reliability improvements. This creates a healthy tension between product velocity and operational stability. Mention this — it signals SRE maturity that stands out at Wells Fargo.
@Component public class PaymentMetrics { private final MeterRegistry registry; private final Counter successCounter; private final Counter failureCounter; private final Timer processingTimer; public PaymentMetrics(MeterRegistry registry) { this.registry = registry; this.successCounter = Counter.builder("payments.processed") .tag("status", "success") .description("Successful payment count") .register(registry); this.processingTimer = Timer.builder("payments.processing.duration") .publishPercentiles(0.5, 0.95, 0.99) // P50, P95, P99 .register(registry); } public void recordSuccess(Duration duration) { successCounter.increment(); processingTimer.record(duration); } } // Structured logging — always include correlation fields MDC.put("traceId", traceId); MDC.put("paymentId", paymentId); MDC.put("accountId", accountId); log.info("Payment processed", Map.of("amount", amount, "status", status)); // → Queryable in Splunk/ELK: traceId=xyz AND paymentId=abc
CREATE INDEX … ONLINE) to fix the root cause. Communicated status updates every 3 minutes to stakeholders.
"I first validated their reasoning before presenting the alternative" — shows emotional intelligence. "I backed the pushback with data and a working PoC" — shows engineering rigour. "Propose a time-boxed spike" — shows pragmatism.
Design a notification system for 50 million users. Push + email + SMS.
Design a URL shortener. What data model and what read/write ratio?
How would you design a rate limiter for the Wells Fargo API Gateway?
What is the difference between a liveness probe and readiness probe?
Liveness: "Is this pod alive?" If fails → K8s restarts the pod. Use for deadlock detection — when the app is running but stuck. Endpoint: /actuator/health/liveness.
Readiness: "Is this pod ready to receive traffic?" If fails → K8s removes pod from Service endpoints (no new traffic). Use for slow startup, DB connections not yet established. Pod stays running but not in rotation.
Key insight: During rolling deployment, readiness gate ensures old pods keep serving until new pod is fully ready. Critical for zero-downtime payment deployments.
What is a PodDisruptionBudget? Why does it matter for payments?
PDB ensures a minimum number of pods remain available during voluntary disruptions (node drain, cluster upgrades). Example: minAvailable: 2 — K8s won't drain a node if it would leave fewer than 2 payment-service pods running. Without PDB, a cluster upgrade could terminate all pods of a service simultaneously → payment outage. Essential for any production financial service on K8s.
Explain GitOps. How does ArgoCD work?
GitOps: Git is the single source of truth for infrastructure and deployment state. Changes are made via PR → ArgoCD detects drift between Git state and cluster state → syncs automatically or on approval. Benefits: full audit trail (every deployment is a git commit), easy rollback (revert the commit), no manual kubectl in production. ArgoCD continuously reconciles desired state (Git) with actual state (K8s cluster).
How do you handle a high-performing engineer who is consistently rude to teammates?
How do you prioritise when your team has more work than capacity?
What's your approach to code reviews?
Code reviews are a teaching tool, not a gatekeeping tool. I distinguish: blocking issues (correctness, security, data risk) vs non-blocking suggestions (style preferences, alternative approaches). I explain the why — not just "this is wrong" but "this pattern causes X problem in our payment context". I aim for reviews within 24 hours — slow reviews kill momentum. I also review my own PRs before requesting others'.
Where do you see yourself in 3 years? Why Wells Fargo specifically?
Answer: "In 3 years I want to be solving systems-level problems at scale — not just writing code but setting technical direction for a domain. Wells Fargo specifically: the combination of real-world financial scale, the modernisation journey from legacy to cloud-native, and the opportunity to work on systems that move real money for real people is genuinely rare. Most companies can't offer this combination of scale and impact."