Senior Backend Engineer Interview Mastery 2026

✓ Strong Answer

I approach this in phases keyed to the actual bottleneck. Phase 1 (10K→100K): vertical scale + CDN for static assets + read replicas + HikariCP pool tuning. Phase 2 (100K→1M): Redis cache for hot reads, async writes via Kafka for non-critical paths, separate read/write data models. Phase 3 (1M→10M): horizontal sharding (consistent hashing), stateless services behind ALB, DB connection pooler (PgBouncer), regional deployment. Key insight: each phase has a different bottleneck — you must measure before optimizing.

✓ Strong Answer

In standard modulo hashing, adding or removing a node remaps nearly all keys — catastrophic for a cache cluster. Consistent hashing places both nodes and keys on a circular ring (hash space 0 to 2^32-1). Each key is served by the first node clockwise from it. When a node is added/removed, only keys in that segment are remapped — O(K/N) keys instead of O(K). Virtual nodes (vnodes) solve the hot-spot problem: each physical node gets 150-200 positions on the ring, ensuring even distribution even with heterogeneous node capacities. I use this for: distributed caches (Redis Cluster, Memcached), sharding routers, and CDN edge server selection.

✓ Strong Answer

Three main scenarios: (1) Cache expiry stampede — many keys expire at same time, all requests fall through to DB simultaneously. Fix: add random jitter to TTLs (TTL = base + random(0, base*0.1)), or use "probabilistic early expiration" (PER) where you refresh slightly before expiry based on request rate. (2) Cold start — after cache flush or restart, every request misses. Fix: cache warming script pre-populates top N keys before going live. (3) Retry storms — circuit opens, all clients retry simultaneously when it re-closes. Fix: exponential backoff with jitter on retries. Also use mutex locking: when cache misses, one thread fetches from DB and populates cache while others wait (promise/future pattern in Java).

✓ Strong Answer

Four main algorithms: (1) Fixed Window — simple Redis counter per time window, but allows 2× burst at window boundary. (2) Sliding Window Log — store timestamp of each request, count within window — accurate but O(N) memory. (3) Sliding Window Counter — hybrid: use two fixed windows weighted by overlap — O(1) memory, ~1% error. (4) Token Bucket — tokens refill at constant rate, requests consume tokens — allows bursts up to bucket size. Leaky Bucket is similar but smooths output. For distributed: use Redis INCR + EXPIRE for fixed window, or Redis + Lua script for atomic sliding window. For multi-region: use local approximate limiting (reduces cross-region latency) and sync periodically.

✓ Strong Answer

Write scaling requires addressing multiple layers: (1) Connection pooling — PgBouncer in transaction mode reduces DB connections by 10-50×. (2) Batching — batch inserts (INSERT ... VALUES (),(),()), write-behind caching with periodic flush. (3) Async writes — accept via Kafka, persist in consumer — decouples write acceptance from DB write. (4) Sharding — horizontal partition by a shard key (user_id, tenant_id). Choose shard key to distribute writes evenly and co-locate related reads. (5) Write-optimized storage — LSM trees (Cassandra, RocksDB) are designed for write-heavy workloads; B-trees (PostgreSQL) optimize for reads. (6) Time-series patterns — for time-series data, partition by time (monthly tables in PostgreSQL) so writes always hit the current hot partition and old partitions are cold.

✓ Strong Answer

CQRS (Command Query Responsibility Segregation) separates the write model (commands) from the read model (queries). Write side: receives commands (CreateOrder, UpdateInventory), applies business rules, emits events. Read side: maintains materialized views optimized for specific query patterns, updated by event consumption. Benefits: read model can be denormalized for specific query needs (no joins), write model can be a proper domain aggregate, both can scale independently. Apply it when: (1) read and write access patterns are very different, (2) you need different consistency guarantees per operation, (3) read model needs heavy denormalization the write model can't accommodate. Cost: eventual consistency between command and query sides, operational complexity (2 data stores), event schema evolution.

✓ Strong Answer

Backpressure is a flow control mechanism where a consumer signals capacity to a producer, causing the producer to slow down rather than overwhelming the consumer. Without it, a fast producer + slow consumer = memory exhaustion and OOM crashes. Implementation approaches: (1) Bounded queues — if the queue is full, producer blocks or rejects. In Java: ArrayBlockingQueue with CallerRunsPolicy in ThreadPoolExecutor (the calling thread runs the task itself, creating backpressure). (2) Reactive Streams (Project Reactor/RxJava) — consumers request N items (demand signaling); producers only emit what's been requested. (3) Kafka consumer — pull model naturally applies backpressure; consumer only fetches when ready. (4) TCP/HTTP — TCP window size and HTTP/2 flow control are built-in backpressure at the protocol level.

✓ Strong Answer

Architecture: JWT for stateless auth (no server-side session lookup needed for auth), Redis for session state that must be server-side (shopping cart, wizard state, temporary files). JWT contains: userId, roles, expiry, tenant. Redis session: userId → {sessionData} with TTL = session timeout. Scaling concerns: Redis Cluster for availability; Redis Sentinel for HA. Session key = sessionId from HttpOnly cookie (never in URL — OWASP). On login: create sessionId, store in Redis, set HttpOnly Secure SameSite=Strict cookie. On each request: extract sessionId from cookie, lookup in Redis (O(1)), merge user data into request context. Expiry: sliding window (EXPIRE reset on each access) vs fixed TTL (simpler, more secure).

✓ Strong Answer

Vertical scaling (scale-up): upgrade CPU/RAM/storage on existing server. Benefits: no code changes, no distributed system complexity, works well up to a point. Limits: diminishing returns, hardware ceiling, single point of failure. Best for: databases (scaling PostgreSQL vertically is often simpler than sharding), stateful services that are hard to distribute. Horizontal scaling (scale-out): add more instances behind a load balancer. Benefits: theoretically unlimited, handles failure gracefully, cost-effective at large scale. Requirements: stateless services, shared storage/cache, distributed coordination. Best for: stateless API servers, web workers, consumer services. In practice: I start with vertical scaling because it's simpler. Move to horizontal when vertical hits diminishing returns or single-point-of-failure is unacceptable. Most production systems use both: horizontally scaled app tier + vertically scaled DB (then read replicas, then sharding).

✓ Strong Answer

Auto-scaling requires: (1) Right metrics — CPU is a lagging indicator. Use application-level metrics: request queue depth, P99 latency, active connections, or custom CloudWatch metrics from the app. (2) Scale-out policy: add X% capacity when metric exceeds threshold for Y minutes (avoid reacting to spikes). (3) Scale-in policy: more conservative than scale-out — longer cooldown, lower threshold, step down slowly to avoid yo-yo effect. (4) Warm-up period — new instances need time to reach steady state (JVM JIT warmup, cache fill). ALB target group has deregistration delay; use health check grace period. (5) Minimum and maximum bounds — minimum for baseline availability, maximum for cost control. (6) Predictive scaling — AWS Predictive Scaling uses ML on historical data to pre-scale before known load patterns (e.g., Monday morning, end of month).

✓ Strong Answer

Hot partitions happen when a partition key concentrates traffic — celebrity users, trending events, time-based keys. Prevention: (1) Composite keys — append a shard suffix: userId#0 through userId#9, distribute writes, scatter-gather reads. (2) Avoid monotonic keys for partition — sequential IDs, timestamps as partition key create write hotspots. Use UUID or hash-based keys. (3) Write sharding for DynamoDB: prefix partition key with a random number 1-N, read from all N shards, merge. N = target throughput / per-partition limit. Mitigation: (1) Caching — cache the hot entity in Redis to absorb reads. (2) Read replicas — for Cassandra, read from any replica; tune consistency level to LOCAL_ONE for hot reads. (3) DynamoDB Adaptive Capacity automatically redistributes capacity to hot partitions — but it's reactive, not instant.

✓ Strong Answer

Capacity planning before launch: (1) Estimate load: expected users × actions/user/day = daily requests. Factor in peak multiplier (typically 3-5× average for consumer apps). (2) Profile the feature: benchmark it under load (k6, Gatling) to get per-request cost in CPU-ms, memory, DB queries, and external calls. (3) Calculate resources: (peak QPS × CPU-ms/request) / (1000ms × core_count × target_utilization%). Target 60-70% utilization to leave headroom. (4) DB sizing: estimate rows/day × row size × retention days = storage. Add index overhead (typically 30-50% of data size). (5) Cache sizing: estimate hot dataset size (top N% of items that receive M% of reads — usually 80/20). (6) Document assumptions so you can verify them post-launch.

✓ Strong Answer

Use the Strangler Fig pattern: (1) Put a proxy/facade in front of the monolith. (2) Identify a bounded context to extract — pick one with clear seams, low coupling to the rest, and a team that owns it. (3) Build the new service alongside the monolith. (4) Migrate traffic to the new service gradually (feature flag → 1% → 10% → 100%). (5) Keep the monolith code as fallback until the new service is proven. (6) Remove the monolith code for that context. Repeat per bounded context. Critical: don't extract a service until you have: circuit breakers, distributed tracing, health checks, and alerting. Each extracted service adds a network hop — measure the latency impact. The proxy (API Gateway) becomes the seam between old and new.

✓ Strong Answer

A service mesh (Istio, Linkerd, Consul Connect) adds a sidecar proxy (Envoy) to each pod that transparently handles: mTLS between services (encryption + identity), circuit breaking, retries, timeouts, distributed tracing injection, load balancing, and traffic splitting (canary deployments). The proxy intercepts all inbound/outbound traffic without code changes. Benefits: language-agnostic (Resilience4j in Java is great, but what about Python/Go services?), centralized observability, zero-trust network security by default. Costs: sidecar resource overhead (50-100MB RAM, ~2ms latency per hop), operational complexity (Istio control plane is notoriously complex), steep learning curve.

✓ Strong Answer

2PC (Two-Phase Commit): Coordinator sends "prepare" to all participants; waits for all to acknowledge; sends "commit". All-or-nothing atomicity. Problems: blocking protocol (if coordinator fails after prepare, participants hold locks indefinitely), high latency (2 round trips minimum), single coordinator SPOF, tight coupling. Best for: systems within a single trust boundary (multiple databases in one service). Saga pattern: sequence of local transactions, each immediately committed. If a step fails, compensating transactions run in reverse order to undo previous steps. Two flavors: (1) Choreography — each service publishes events; next service listens and reacts. (2) Orchestration — a Saga orchestrator (process manager) calls each service and tracks state. Sagas are eventually consistent — there is a window where the system is partially committed.

✓ Strong Answer

Two models: (1) Client-side discovery — client queries the service registry (Eureka, Consul), gets a list of instances, picks one (round-robin, least connections). Load balancing logic is in the client (Spring Cloud LoadBalancer). Pros: client controls load balancing algorithm. Cons: discovery logic in every client. (2) Server-side discovery — client calls a load balancer/router (AWS ALB, Kubernetes Service), which queries the registry and forwards. Pros: language-agnostic. Cons: one more hop. In Kubernetes, this is built-in: Kubernetes DNS (svc-name.namespace.svc.cluster.local) + kube-proxy does server-side discovery transparently. Service registry: etcd (Kubernetes), Consul (multi-platform), Eureka (Spring Cloud Netflix). Registration: either self-registration (service registers itself on startup) or third-party registration (orchestrator registers — Kubernetes does this).

✓ Strong Answer

Defense in depth across multiple layers: (1) Timeouts — every service-to-service call needs a timeout. Without it, thread pool exhaustion cascades. Aggressive timeouts: 200ms for cache, 1s for DB reads, 2s for external APIs. (2) Circuit Breaker — Resilience4j: after N failures in M seconds, circuit opens; sends fail-fast response without calling downstream. After cooldown, sends probe request (HALF_OPEN). (3) Bulkhead — separate thread pools per downstream dependency. Failure in one dependency doesn't exhaust the global thread pool. (4) Retry with exponential backoff + jitter — avoid retry storms. Max 3 attempts with jitter. (5) Fallback — degrade gracefully: return cached response, empty response, or default. (6) Load shedding — reject requests early (return 503) when the service is overloaded rather than queuing them and getting slower for everyone.

✓ Strong Answer

URL versioning (/v1/users, /v2/users): explicit, easy to route, easy to cache, easy to document. Downside: clients must update URL and you run multiple versions concurrently. Header versioning (Accept: application/vnd.myapp.v2+json): clean URLs, but harder to test in browser, curl. Query param (?version=2): simple but pollutes the query space. Best practice hybrid: URL versioning for major breaking changes, header for minor variations. Breaking changes that require new version: removing a field, changing a field type, changing semantics of a field, changing authentication. Non-breaking (no version bump): adding optional fields, adding new endpoints. Backward compatibility contract: new service must accept old request format AND return old response format for existing consumers. Consumer-driven contract testing (Pact) validates this automatically in CI.

✓ Strong Answer

Distributed tracing works by propagating a trace context (traceId + spanId) through every request. Implementation: (1) Instrumentation — Spring Boot auto-configures Micrometer Tracing (replacing Spring Cloud Sleuth) with Zipkin/Jaeger exporter. Each incoming request gets a traceId if not present; each outbound call creates a child span. (2) Context propagation — W3C Trace Context headers (traceparent, tracestate) or B3 headers (X-B3-TraceId, X-B3-SpanId) passed via HTTP headers and Kafka message headers. (3) Sampling — 100% sampling in dev, typically 1-10% in production (head-based sampling), or tail-based sampling (Jaeger adaptive, sample errored requests at 100%). (4) Correlation — correlate trace IDs in logs (MDC in Java) so you can find the log lines for a given trace. (5) Storage + UI — Jaeger or Zipkin stores spans; UI shows waterfall timeline per trace.

✓ Strong Answer

The naive approach (DB write + Kafka publish in sequence) has a fatal flaw: DB write succeeds but Kafka publish fails = event lost. Or Kafka publishes but DB commit fails = event without corresponding state change. Fix — Outbox Pattern: (1) In the SAME database transaction, write the business entity AND write an OutboxEvent row (topic, key, payload, status=PENDING). (2) Transaction commits atomically — both or neither. (3) A separate publisher process polls the outbox table for PENDING events and publishes to Kafka. (4) On Kafka ack, mark the row as PUBLISHED. (5) If publisher crashes between Kafka ack and DB update, the event will be republished — therefore consumers must be idempotent (handle duplicate messages). Alternatives to polling: Debezium CDC (Change Data Capture) reads the DB WAL and publishes change events — lower latency, no polling overhead.

✓ Strong Answer

Synchronous (REST/gRPC): request-response, immediate result, simpler to reason about. Use when: the caller needs the result to continue (payment processing, auth check, inventory reservation), latency is critical, or the result is needed in the current user-facing request. gRPC advantages over REST: binary protocol (smaller payload, faster serialization), strongly typed (proto files as contract), bidirectional streaming, built-in code generation. Asynchronous (Kafka/SQS): fire and forget, decoupled producer/consumer, natural backpressure, replay capability, resilient to consumer downtime. Use when: operation is not on the critical path (send email, update analytics, notify downstream), producer and consumer should scale independently, or you need event replay/audit. Anti-pattern: using async for operations that require immediate confirmation creates complex UX (polling, webhooks back to client).

✓ Strong Answer

Two separate concerns: (1) Liveness — is the process alive? Simple: returns 200. Used by Kubernetes to decide whether to kill and restart. Should almost never fail — if it does, the pod restarts. Only check: is the JVM running? Can the event loop execute? (2) Readiness — is the service ready to accept traffic? Checks dependencies: DB connection pool has available connections, Redis is reachable, any required caches are warmed, dependent services are reachable. Used by Kubernetes/ALB to route traffic. Should fail during startup (before warm-up complete) and during graceful shutdown. Spring Boot Actuator: /actuator/health splits into liveness (/actuator/health/liveness) and readiness (/actuator/health/readiness) with separate groups. Custom indicators: implement HealthIndicator interface to add DB check, cache check, etc.

✓ Strong Answer

Externalized configuration (12-Factor App): config should not be in code. Strategy: (1) Environment variables for simple non-secret config (feature flags, timeouts). (2) Config server for centralized, versioned config: Spring Cloud Config Server (backed by Git repo) or AWS AppConfig. Services pull config at startup; config changes can be pushed (Spring Cloud Bus + @RefreshScope for live updates). (3) Secrets management (separate from config): AWS Secrets Manager or HashiCorp Vault for DB passwords, API keys, certificates. Never store secrets in env vars (visible in ps, log dumps) or Git. (4) Per-environment profiles: Spring profiles (application-dev.yml, application-prod.yml) for environment-specific settings. (5) Config validation: fail fast at startup if required config is missing (using @ConfigurationProperties + @Validated).

✓ Strong Answer

Core components: (1) Notification API — accepts events from producers (OrderService, PaymentService). Returns immediately after enqueuing. (2) Kafka topics per channel: notification.email, notification.push, notification.sms. (3) Channel workers: Email worker (SendGrid/SES), Push worker (FCM for Android, APNs for iOS), SMS worker (Twilio). Each is independently scaled. (4) User preference service — before sending, check if user has opted out, preferred channel, quiet hours. (5) Template service — localized templates per event type + locale. (6) Rate limiting per user — no more than N notifications/hour per channel. (7) Delivery tracking DB — record sent/delivered/failed status per notification. (8) Retry queue — failed deliveries retry with backoff. Fan-out challenge: if 1M users need to be notified of a flash sale, Kafka fan-out handles this naturally — producer publishes one event, worker reads and expands to individual user notifications.

✓ Strong Answer

Architecture: (1) Centralized Redis Cluster with Lua scripts for atomic operations. Token bucket per (userId, apiKey, endpoint) combination. (2) Rate limit rules stored in a config service — each service type has different limits (free: 100/hr, paid: 10K/hr). (3) Rate limiter as shared library (or sidecar) — each service uses the library, which talks to Redis. (4) Response headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset — standard practice. (5) Sliding window counter implementation: store count in current window + previous window weighted by overlap percentage — O(1) memory per user. Lua script ensures atomicity: GET, compute, SET in one atomic operation. (6) Global vs per-service limits: enforce both — prevent one service from consuming all quota even if per-service limit is fine.

✓ Strong Answer

Estimation: 100K reads/sec, assume 1K writes/sec (100:1 read:write ratio). Short code: 7 chars × 62 (a-z, A-Z, 0-9) = 62^7 = 3.5 trillion unique codes (enough for 100 years). Components: (1) Write path: generate short code (base62(random 64-bit ID) or MD5+truncate), store in DB (longURL, shortCode, userId, createdAt, expiresAt, clickCount). (2) Read path: shortCode → Redis lookup (miss → DB → populate Redis) → 301/302 redirect. Redis TTL = 24-48h for hot links. (3) Custom short codes: check availability + store. (4) Analytics: Kafka event for each click (userId, shortCode, timestamp, referer, user-agent, IP → geo). (5) DB: PostgreSQL with index on shortCode. At 100K reads/sec → nearly all served from Redis (O(1) lookup). (6) CDN: consider Cloudflare in front — cache redirects at edge.

✓ Strong Answer

Data structure: Redis Sorted Set (ZSET) — O(log N) add/update, O(log N + M) range query. Commands: ZADD leaderboard score userId (upsert score), ZRANGE leaderboard 0 99 WITHSCORES REV (top 100), ZRANK leaderboard userId (user's rank). Score updates: user completes a game → increment score ZINCRBY leaderboard delta userId. Persistence: Redis AOF for durability, periodic snapshot to PostgreSQL for leaderboard history. Leaderboard types: (1) Global (all time), (2) Weekly (new ZSET per week, TTL), (3) Friends (per-user set of friend scores — fan-out on write). At 10M concurrent users with frequent score updates, batch score updates: buffer changes in memory, flush to Redis every 1-5 seconds (reduces ZADD calls by 1000×). Real-time display: WebSocket push — when user's rank changes significantly (> N positions), push update.

✓ Strong Answer

Requirements: jobs run at specified times, exactly once (even with multiple scheduler instances), failures are retried, job history is tracked. Components: (1) Job registry — DB table: jobId, cronExpression, handlerType, payload, enabled, lastRun, nextRun. (2) Scheduler cluster — multiple instances for HA, but only one executes a given job at a time. Leader election via Redis SETNX or Zookeeper, or use distributed lock (each instance tries to lock jobId before executing). (3) Job execution — pull jobs due in next N seconds, acquire distributed lock per job, execute, release lock, update nextRun. (4) Worker pool — for long-running jobs, submit to async worker pool (Kafka + consumers) rather than executing in scheduler thread. (5) Job history DB — record each execution: start, end, status, error. (6) Dead letter handling — jobs that fail N times → alert + move to DLQ.

✓ Strong Answer

Two-tier architecture: (1) Real-time tier (latency <100ms, in payment critical path): rule engine + lightweight ML model. Rules: velocity checks (N transactions in M minutes per card/device/IP), amount anomaly (this amount vs user's historical average), location anomaly (transaction in Mumbai 5 min after one in Delhi), known bad lists (stolen card numbers, blacklisted devices). Feature store: Redis for real-time features (recent transaction count, last location). Lightweight model: gradient boosted tree (XGBoost) loaded in memory, <10ms inference. Decision: allow / flag / block. (2) Async tier (for complex analysis): Kafka event for every transaction → Flink/Spark Streaming for complex pattern detection (ring patterns, mule accounts, velocity across merchant categories). Decisions from async tier feed back to update user risk scores used in real-time tier.

✓ Strong Answer

Components: (1) Trie data structure in memory — each node stores top N suggestions sorted by frequency. Query: O(L) where L = query length, then return pre-sorted suggestions. (2) Persistent storage — trie too large for single machine → shard by first letter(s). Use Redis with sorted sets per prefix: ZADD prefix:se 1000 "search engine", 950 "settings", ... — ZRANGE to get top N. (3) Data pipeline: clickstream → Kafka → Flink aggregates search frequency → batch update prefix stores. (4) Cache: popular prefixes cached at CDN edge. (5) Personalization: blend global suggestions with user's recent searches and location. (6) Debouncing: client sends request after 300ms of no typing to avoid flooding. (7) Cancellation: if previous request hasn't returned, cancel it when new character typed.

✓ Strong Answer

Multi-AZ (within one AWS region): AWS manages two or more AZs, physically separate data centers with independent power/cooling/networking, connected via low-latency links (<2ms). Handles: AZ failure (1-4 times/year industry average). Components: ALB (spans AZs by default), RDS Multi-AZ (synchronous replication, automatic failover in 60-120s), ECS/EKS tasks spread across AZs, ElastiCache with replica in second AZ. Cost: ~2× single-AZ. SLA achievable: 99.99%. Multi-region: active-passive (Route 53 failover routing) or active-active (Route 53 latency routing). Handles: region failure (rare but happens — us-east-1 has had major outages). Data replication: RDS cross-region read replicas (async, RPO = replication lag), DynamoDB Global Tables (multi-active), S3 Cross-Region Replication. Cost: 3-5× single-AZ. SLA achievable: 99.999%+ with active-active. Decision: 99.9% → single AZ. 99.95% → multi-AZ. 99.99% → multi-AZ active. 99.999% → multi-region.

✓ Strong Answer

SQS (Simple Queue Service): point-to-point queue, one consumer per message, retention up to 14 days. Standard queue: best-effort ordering, at-least-once, high throughput (unlimited). FIFO queue: exactly-once, strict ordering per message group, 3K TPS. Use for: async task processing, decoupling services, work queues. SNS (Simple Notification Service): pub/sub fan-out, one topic → multiple subscribers (SQS, Lambda, HTTP, email, SMS). Push-based. Use for: fan-out patterns (one event → multiple processors), cross-account notifications. SNS + SQS combination: SNS fan-out to multiple SQS queues (each consumer has its own queue, can process independently and at its own rate). Kinesis Data Streams: ordered, replayable (7-day retention), shard-based partitioning, 1MB/s per shard. Use for: real-time analytics, event sourcing, clickstream processing, ML feature engineering. EventBridge: event bus with schema registry + routing rules, native integration with 200+ AWS services. Use for: event-driven architecture with multiple AWS services, scheduled events (EventBridge Scheduler), third-party SaaS integrations.

✓ Strong Answer

Blue-green with ALB: (1) Blue = current production (Target Group A). Green = new version (Target Group B). (2) Deploy new version to green. (3) Run smoke tests + integration tests against green directly. (4) Use ALB weighted target groups: start with 90% blue / 10% green, monitor error rate and latency. (5) Gradually shift: 50/50 → 10/90 → 0/100. (6) If green has issues, set weight back to 100% blue (instant rollback). (7) Terminate blue after confidence period (30-60 min). ECS CodeDeploy integration automates this. Considerations: (a) DB schema changes must be backward compatible — old blue code must work with new schema. (b) Sticky sessions — if users are pinned to blue, they must not suddenly go to green mid-session. (c) Cache invalidation — green instances with empty caches will get cold-start latency spikes.

✓ Strong Answer

Systematic approach: (1) Identify waste: AWS Cost Explorer + Trusted Advisor. Find idle EC2 (< 10% CPU), unused EBS volumes, unattached Elastic IPs, oversized RDS instances. (2) Right-sizing: use AWS Compute Optimizer recommendations. Most teams over-provision by 2-4×. (3) Commitment pricing: Reserved Instances (1yr/3yr, up to 72% discount) or Savings Plans (more flexible, applies to EC2 + Fargate + Lambda, up to 66%) for baseline, predictable workloads. (4) Spot Instances for fault-tolerant, interruptible workloads (batch jobs, CI/CD workers, development) — up to 90% discount. (5) Data transfer costs: often overlooked. Minimize cross-AZ data transfer (free within AZ, $0.01/GB across AZ). Keep DB and app in same AZ for reads. Use S3 Transfer Acceleration only when needed. (6) Storage: S3 Intelligent Tiering for infrequently accessed objects; EBS gp3 instead of gp2 (same cost, 20% better performance); RDS storage auto-scaling prevents over-provisioning.

✓ Strong Answer

(1) AWS Secrets Manager: store DB credentials, API keys, certificates. Automatic rotation for RDS/Redshift credentials (Lambda function rotates and updates the DB password). Versioning of secrets (AWSPREVIOUS, AWSCURRENT, AWSPENDING) enables zero-downtime rotation. (2) AWS Systems Manager Parameter Store: for non-secret config (feature flags, endpoints). SecureString type uses KMS encryption. Cheaper than Secrets Manager for high-volume reads. (3) IAM Role-based access: EC2 instance profile / ECS task role / Lambda execution role — no credentials stored in code or env vars. The role assumes access to Secrets Manager. (4) KMS encryption: Secrets Manager encrypts with KMS. Use customer-managed KMS keys (CMK) for regulatory requirements and separate key policies per application. (5) Secret access in code: AWS SDK reads secret at startup, cache in memory, refresh periodically. Never log secret values.

✓ Strong Answer

Structured incident response: (1) Declare incident immediately — don't spend 10 min trying to fix before telling anyone. Create incident channel. (2) Assign roles: Incident Commander (IC — coordinates), Technical Lead (investigates), Comms Lead (updates stakeholders). IC is NOT the one debugging — they coordinate. (3) Mitigation first, root cause second. Can we rollback? Feature flag off? Failover to backup? Reduce blast radius immediately. (4) Runbook execution — for known failure modes, follow the runbook. Don't wing it under pressure. (5) Timeline — document every action in real-time (Slack messages, PagerDuty notes). (6) Stakeholder update every 15-30 min even if there's nothing new — "still investigating, no ETA" is better than silence. (7) Postmortem — within 48h: timeline, root cause, contributing factors, action items. Blameless. Learn, don't punish.

✓ Strong Answer

Monitoring = knowing when something is wrong (metrics + alerts). Observability = understanding WHY it's wrong from the outside, without deploying new code. The three pillars: (1) Metrics — numeric aggregations over time. USE method for resources (Utilization, Saturation, Errors). RED method for services (Rate, Errors, Duration). Tools: Prometheus + Grafana, CloudWatch, DataDog. (2) Logs — structured (JSON) logs with correlation IDs. Every request gets a requestId; every log line in that request includes it. Avoid log levels: DEBUG in dev, INFO in prod (WARN/ERROR should alert). Centralize: ELK Stack or CloudWatch Logs Insights. (3) Distributed Traces — full request trace across services (traceId → spanId hierarchy). OpenTelemetry → Jaeger/Zipkin/Datadog APM. The difference: monitoring tells you the DB is slow (symptom). Observability lets you trace one slow request across 5 services to find the exact query in Service C that's causing it.

✓ Strong Answer

Blameless postmortem structure: (1) Incident summary: what happened, impact (users affected, revenue lost, duration). (2) Timeline: exact sequence of events with timestamps — when did the issue start, when was it detected, when was it escalated, when was it mitigated. (3) Root cause analysis — use 5 Whys technique to find the systemic cause, not just the proximate cause. Stop when you reach a fixable process or system gap. (4) Contributing factors — list everything that made the incident worse or harder to detect. Missing alert? Unclear runbook? Slow rollback? Each is an action item. (5) What went well — acknowledge the things that worked. (6) Action items — specific, assigned, dated. "Improve monitoring" is not an action item. "Add alert for connection pool exhaustion before it hits 90% in JIRA-123, due in 2 weeks" is. (7) Blameless means: the system allowed a human to make a mistake — fix the system. Naming and shaming is banned.

✓ Strong Answer

Alert principles: (1) Page on symptoms, not causes. "P99 latency > 500ms for 5 minutes" is a symptom (users are affected). "CPU > 80%" is a cause (may or may not affect users). CPU at 80% with P99 = 50ms → not worth waking someone. (2) Every alert should be actionable. If the response to an alert is "wait and see" or "no action needed," it shouldn't page. (3) Categorize: P0/P1 (page immediately, wake at 3 AM), P2 (ticket during business hours), P3 (informational). P0: service down or SLO breach imminent. P1: degraded but operating, trending toward breach. (4) Alert on error budget burn rate, not absolute error rate. 5% error rate for 1 minute might be fine. Same 5% sustained for 1 hour is burning your monthly error budget in hours. (5) Tune aggressively — every false positive trains on-call to ignore alerts. Review alert signal-to-noise ratio monthly.

✓ Strong Answer

Systematic approach: (1) Use distributed traces (Jaeger/Zipkin) to find where in the call chain the latency is. P99 of the whole request is not actionable — P99 per span tells you which service and which operation is slow. (2) Check the slowest span: is it DB? External API? Computation? (3) For DB slowness: check slow query log (PostgreSQL: log_min_duration_statement=100ms), run EXPLAIN ANALYZE on the slow query, look for Seq Scan on large tables (missing index), N+1 queries (check Hibernate SQL logging). (4) For external API: check if it's the vendor's problem or network. Add circuit breaker + timeout if not present. (5) For computation: profile (Java Flight Recorder / async-profiler) to find CPU hotspots. (6) Check for resource contention: DB connection pool exhaustion (HikariCP metrics: pending connections, connection timeout rate), thread pool saturation, GC pauses (Java GC logs, G1GC pause times). (7) Check if P99 latency correlates with traffic spikes — might be a queuing effect (Little's Law).

✓ Strong Answer

Adding NOT NULL column to a 100M-row table naively causes: table lock for minutes (PostgreSQL acquires AccessExclusiveLock for ALTER TABLE) = downtime. Safe approach (expand-contract pattern): (1) Expand: ADD COLUMN new_col VARCHAR(255) NULL — null allowed, instant schema change, no lock. (2) Backfill: UPDATE table SET new_col = derived_value WHERE new_col IS NULL — do in batches of 1000 rows with LIMIT + sleep to avoid lock escalation and replication lag. (3) Deploy new code that writes to both old_col and new_col on every write. (4) Verify backfill is 100% complete. (5) Deploy code that reads from new_col. (6) Contract: ALTER TABLE ADD CONSTRAINT ... NOT NULL — safe once all rows have values (PostgreSQL 12+ can do this with NOT VALID + VALIDATE CONSTRAINT without full lock). (7) Drop old column (deferred — wait for all code using it to be removed). For index creation: CREATE INDEX CONCURRENTLY — builds index without locking writes (takes longer but safe).

✓ Strong Answer

Decision framework: (1) ACID requirements: if you need transactions (financial, inventory, booking), relational DB is usually the right choice. PostgreSQL or MySQL. (2) Data model: tabular + relationships → SQL. Document-oriented (variable schema, nested data) → MongoDB. Key-value (simple lookups by ID) → Redis or DynamoDB. Time-series → TimescaleDB or InfluxDB. Graph → Neo4j. (3) Scale: SQL scales vertically + read replicas (sufficient for most companies). NoSQL designed for horizontal scaling. But: PostgreSQL with partitioning + Citus (horizontal sharding extension) scales very far. (4) Query patterns: complex joins, reporting, ad-hoc queries → SQL. High-throughput simple key lookups → NoSQL. Full-text search → Elasticsearch. (5) PostgreSQL vs MySQL: PostgreSQL has better standards compliance, better concurrency (MVCC without read locks), richer types (JSON, arrays, ranges, full-text), better extensions. MySQL is faster for simple read-heavy workloads and has better RDS read replica support. I default to PostgreSQL for new services.

✓ Strong Answer

Sharding horizontally partitions data across multiple DB instances. Types: (1) Range-based: shard by ID ranges (1-1M → shard 1, 1M-2M → shard 2). Simple routing, but hot spots if recent data is heavy. (2) Hash-based: hash(shardKey) % numShards → shard. Even distribution, but adding shards requires rehashing. (3) Consistent hashing: shardKey → ring → nearest node. Adding nodes only remaps K/N keys. (4) Directory-based: shard map in a lookup service (shardKey → shard ID). Flexible but adds latency. Shard key choice: must distribute writes evenly (high cardinality), co-locate related reads (userId good for user-centric apps). Bad shard keys: timestamp (hot shard for recent data), country (uneven distribution). Cross-shard queries: avoid or accept the complexity. Cross-shard JOINs require scatter-gather (query all shards, merge results in application). Transactions across shards: Saga pattern (compensating transactions).

✓ Strong Answer

Normal forms: 1NF (atomic values, no repeating groups), 2NF (1NF + no partial dependencies on composite key), 3NF (2NF + no transitive dependencies — non-key columns depend only on the key). BCNF (stricter 3NF). Normalization benefits: no update anomalies (change in one place propagates everywhere), reduced storage, data integrity. Denormalization: intentionally introduce redundancy to optimize read queries. When to denormalize: (1) Join-heavy read path is a performance bottleneck and adding indexes doesn't help. (2) Reporting queries that aggregate across many tables. (3) Read:write ratio is very high (>100:1) — maintaining denormalized copies is worth the write cost. Example: store user.name directly in orders table (denormalized) to avoid joining users table on every order query. Consistency trade-off: if user changes their name, must update all orders (or accept stale name in old orders).

✓ Strong Answer

MVCC (Multi-Version Concurrency Control): instead of using locks for reads, the DB maintains multiple versions of each row. Each transaction sees a snapshot of the DB as of its start time — it reads the version of each row that was committed before the transaction began. Result: readers never block writers, writers never block readers (unlike lock-based systems). PostgreSQL implementation: each row has xmin (transaction ID that created this version) and xmax (transaction ID that deleted/updated this row, or null if current). A transaction can see a row if xmin ≤ current_txid AND (xmax is null OR xmax > current_txid). UPDATE doesn't modify the row in-place — it creates a NEW row (new xmin) and marks the old row with xmax. DELETE marks the old row with xmax. Old row versions (dead tuples) are cleaned up by VACUUM. Transaction isolation levels in PostgreSQL: READ COMMITTED (default — each statement sees committed data at statement start), REPEATABLE READ (transaction sees snapshot at transaction start), SERIALIZABLE (detects serialization anomalies).

✓ Strong Answer

Systematic process: (1) Run EXPLAIN ANALYZE (not just EXPLAIN) to see actual rows, actual time, and actual loops. (2) Identify the most expensive node: Seq Scan on large table = missing index or filter too loose. Hash Join vs Nested Loop — nested loop with inner Seq Scan is O(N²). Sort = potential missing index. (3) Indexes first: confirm the relevant index exists. Check pg_stat_user_indexes for actual usage. Partial indexes (WHERE clause on index) dramatically reduce size. Composite indexes: column order matters — put equality conditions before range conditions. (4) Check cardinality: if a column has 3 distinct values, an index won't help (low cardinality). (5) JOIN order: PostgreSQL optimizer usually gets this right, but FORCE ORDER hint can help if not. (6) Check for N+1: if the query is in a loop (ORM pattern), address at ORM level (JOIN FETCH, @EntityGraph). (7) Partitioning: query on a partitioned table should use partition pruning (check EXPLAIN for "Append" node with pruned partitions). (8) Analyze table statistics: ANALYZE runs to update planner statistics; stale stats = bad query plans.

✓ Strong Answer

Window functions perform calculations across a set of rows related to the current row WITHOUT collapsing them (unlike GROUP BY). Syntax: FUNCTION() OVER (PARTITION BY ... ORDER BY ... ROWS/RANGE ...). Key functions: ROW_NUMBER() — unique sequential number per partition. RANK() — same rank for ties, gaps after ties. DENSE_RANK() — no gaps. LAG(col, N) / LEAD(col, N) — access previous/next N rows' value. SUM(col) OVER (...) — running total. FIRST_VALUE / LAST_VALUE — first/last in window. Example use cases: (1) Rank customers by spend per category: RANK() OVER (PARTITION BY category ORDER BY total_spend DESC). (2) Running total: SUM(amount) OVER (ORDER BY created_at ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW). (3) Month-over-month growth: (current_month - LAG(current_month) OVER (ORDER BY month)) / LAG(current_month). (4) Deduplicate: ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at) = 1 to get earliest record per email.

✓ Strong Answer

B-tree (Balanced Tree): default PostgreSQL index. Stores keys in sorted order in a balanced tree. O(log N) lookups. Supports: equality (=), range (<, >, BETWEEN), ORDER BY without sort, LIKE 'prefix%'. Structure: root → internal nodes → leaf nodes (which contain actual row pointers or heap pointers). Each leaf page is 8KB (PostgreSQL default). Bloom filters: probabilistic, space-efficient, equality checks only, no false negatives, some false positives. Hash: O(1) equality lookup, but NOT SUPPORTED by PostgreSQL's WAL for crash recovery (PostgreSQL supports hash but it's rarely used; use B-tree for equality too). GIN (Generalized Inverted Index): for multi-valued data — full-text search (tsvector), JSONB containment (@>), arrays (&&, @>). Stores posting lists (key → list of row locations). GiST (Generalized Search Tree): for geometric types (PostGIS), range types (&&, @>, <->). Framework for custom access methods. BRIN (Block Range Index): extremely small index for monotonically increasing columns (timestamps). Good for time-series partitioned tables.

✓ Strong Answer

N+1 problem: loading N parent entities, then for each entity issuing 1 additional query to fetch child entities. Result: 1 + N queries instead of 1 query with a JOIN. Example with Hibernate: `List<Order> orders = orderRepo.findAll();` (1 query) then `orders.forEach(o -> o.getItems().size());` (N queries — one per order because items are LAZY-loaded). Solutions: (1) JOIN FETCH in JPQL: `SELECT o FROM Order o JOIN FETCH o.items` — one query with JOIN. (2) @EntityGraph on repository method: `@EntityGraph(attributePaths="items")` — Spring Data generates JOIN FETCH automatically. (3) @BatchSize(size=100) on the collection: Hibernate loads items in batches of 100 rather than 1-by-1 (reduces to N/100 + 1 queries). (4) DTO projection: use a JPQL constructor expression or native query to fetch exactly what you need — bypasses entity graph entirely. (5) SQL level: explicit JOIN. At SQL level: always prefer a single query with JOIN over application-side loops.

✓ Strong Answer

DynamoDB key design: Primary Key = Partition Key (PK) + optional Sort Key (SK). All data for the same PK is stored together — enables efficient range queries on SK. Single-table design: store all entity types in one table with composite keys. Example: PK="USER#user1", SK="PROFILE" for user data; PK="USER#user1", SK="ORDER#2024-01-01" for orders. Benefits: single round trip for all user data (query on PK="USER#user1" returns all items), no joins needed. GSIs: PK is the existing attribute you want to query by. GSI has its own PK+SK — you project which attributes to include. GSI consistency: eventually consistent reads (or strongly consistent at 2× cost). Multi-table design: one table per entity, familiar relational approach. Benefits: simpler to reason about, easier DynamoDB console browsing. Drawbacks: multi-entity queries require multiple round trips (no joins). Choose based on access patterns: if you need single-round-trip fetches of multiple entity types → single-table. If entities are truly independent → multi-table.

✓ Strong Answer

MongoDB stores BSON (Binary JSON) documents in collections. WiredTiger storage engine (default since 3.2): document-level locking (not collection-level), MVCC for concurrency, compression (Snappy or zstd). Indexes: B-tree, same fundamentals as PostgreSQL but on document fields including nested. Aggregation pipeline: MongoDB's equivalent of SQL GROUP BY/JOIN — stages (match, group, project, lookup, sort, limit). Lookup stage is left outer join between collections — expensive, use sparingly. Sharding: automatic horizontal sharding via mongos router, config servers, shard servers. Choose MongoDB when: (1) Document model naturally fits the data (product catalog with variable attributes, user profiles with different fields per user type). (2) Schema is genuinely variable and schema-on-write is valuable. (3) Geospatial queries ($near, $geoWithin) — MongoDB has excellent geo support. (4) Hierarchical data that's always read together (avoid joins). Choose PostgreSQL when: (1) You need ACID transactions across multiple entities. (2) Complex joins and reporting are required. (3) The data is genuinely relational.

✓ Strong Answer

Choose Cassandra when: (1) Write throughput is massive (100K+/sec) and linear scalability is required. (2) Time-series data with time-based clustering key (sensor data, log storage, IoT). (3) Multi-region active-active (LOCAL_QUORUM per region). (4) No complex queries — pure key lookups or time-range scans on known partitions. Limitations: (1) No JOINs. (2) No ad-hoc queries — must know access patterns at design time. (3) Read performance is slower than write. (4) Eventual consistency by default — last-writer-wins conflict resolution (last write timestamp wins). (5) Deletes use tombstones (marker for deleted data) — excessive deletes cause compaction overhead and performance issues.

✓ Strong Answer

Ordering: guaranteed within a partition, NOT across partitions. Messages with the same key always go to the same partition (hash(key) % numPartitions), preserving order for that key. If ordering across the entire topic is required: single partition (limits throughput). Delivery semantics: (1) At-most-once: auto-commit offset before processing. If consumer crashes after commit but before processing, message is lost. (2) At-least-once (default): process then commit offset. If consumer crashes after processing but before commit, message is reprocessed. Consumers must be idempotent. (3) Exactly-once (Kafka transactions): Producer: enable.idempotence=true (prevents duplicate sends, sequence numbers per partition-producer), transactional.id set (enables transactions). Consumer: isolation.level=read_committed (only reads committed transactions). With these settings, Kafka guarantees exactly-once end-to-end (within Kafka — not across external systems like DB). The transactional pattern: producer.beginTransaction(); produce to topic A; produce to topic B; consumer.sendOffsetsToTransaction(offsets, groupId); producer.commitTransaction();

✓ Strong Answer

ZooKeeper in old Kafka: stored cluster metadata (topic configs, partition assignments, broker list, consumer group offsets). Every broker connected to ZooKeeper. ZooKeeper was a separate cluster to operate (typically 3-5 nodes), a separate failure domain, and a scaling bottleneck (metadata operations serialized through ZK leader). KRaft (Kafka Raft Metadata mode): Kafka's own built-in consensus protocol (based on Raft) replaces ZooKeeper. Metadata is stored in a special internal Kafka topic (__cluster_metadata). Dedicated controller nodes (can overlap with broker nodes) run the Raft consensus for metadata. Benefits: single system to operate, faster metadata propagation (controller election in seconds vs 10s+ with ZK), supports larger clusters (ZK struggled with 200K+ partitions), simpler deployment. Timeline: Kafka 2.8 (preview), 3.3 (production-ready), 3.9 (last ZK release), Kafka 4.0 (ZK removed entirely). Migration: one-way migration tool available in 3.9 → 4.0. Cannot run KRaft and ZooKeeper simultaneously. Cannot migrate back to ZooKeeper.

✓ Strong Answer

Poison message = a message that consistently causes consumer processing to fail (corrupt data, unexpected format, bug triggered by specific data). Without handling: consumer gets stuck on the message, lag grows, all downstream processing halts. Strategy: (1) Retry with backoff — wrap consumer logic in try-catch, retry N times with exponential backoff. (2) Dead Letter Topic (DLT) — after N retries, publish failed message to a DLT (naming convention: topic-name.DLT). Include error metadata in headers: original topic, partition, offset, error message, timestamp. (3) DLT monitoring — alert when DLT has messages (should be empty in healthy system). Separate consumer process to inspect + replay or discard DLT messages. (4) Spring Kafka: DefaultErrorHandler (non-blocking retry), SeekToCurrentErrorHandler, DeadLetterPublishingRecoverer. (5) Schema validation — validate message schema before processing; reject malformed messages immediately to DLT without retry.

✓ Strong Answer

Kafka Streams: Java library (not a separate cluster) that runs inside your application. Reads from Kafka, processes, writes back to Kafka. Processing model: stateless operations (filter, map, flatMap), stateful operations (aggregations, joins) with state stored in RocksDB (local) + backed up to Kafka changelog topic. Fault tolerance: on consumer group rebalance, state is restored from changelog topic. Windowing: tumbling, hopping, sliding, session windows. Exactly-once: supported. Best for: microservice-scoped stream processing that naturally produces Kafka output, teams already using Kafka who want to avoid a separate cluster. Apache Flink: separate cluster (JobManager + TaskManagers), distributed, fault-tolerant stream processing. More powerful: complex windowing, SQL (Flink SQL), batch+stream unified API, larger state storage (RocksDB + distributed state backend like S3). Best for: organization-wide data pipelines, complex CEP (Complex Event Processing), unifying batch and streaming, when processing complexity exceeds what Kafka Streams handles cleanly.

✓ Strong Answer

Spring implements @Transactional via AOP proxy — either JDK dynamic proxy (interface-based) or CGLIB proxy (class-based). When you call an @Transactional method, the call goes through the proxy first, which opens a transaction, then delegates to your bean. Rollback: by default, only on RuntimeException (unchecked). For checked exceptions: use @Transactional(rollbackFor=Exception.class). Transaction binding: transaction is bound to the current thread via ThreadLocal (TransactionSynchronizationManager). Propagation (critical): REQUIRED (default) — if caller has a transaction, the callee joins it; if not, a new one is created. REQUIRES_NEW — always creates a new transaction, suspends the outer one. Common pitfalls: (1) Self-invocation — calling an @Transactional method from within the same bean bypasses the proxy → transaction doesn't apply. Fix: inject self or use ApplicationContext.getBean(). (2) @Transactional on private methods — proxy can't intercept private methods. Must be public. (3) Checked exceptions not rolling back by default. (4) LazyInitializationException — accessing a lazy relationship after the transaction closes.

✓ Strong Answer

Mechanism: (1) @EnableAutoConfiguration (implicit in @SpringBootApplication) triggers AutoConfigurationImportSelector. (2) It reads META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Spring Boot 3+) or META-INF/spring.factories (older) from all JARs on the classpath. (3) Each entry is a @Configuration class annotated with @Conditional annotations: @ConditionalOnClass (only if class is on classpath), @ConditionalOnMissingBean (only if you haven't defined your own bean), @ConditionalOnProperty (only if property is set), @ConditionalOnWebApplication, etc. (4) Auto-configuration classes are ordered (before/after) to handle dependencies. Example: DataSourceAutoConfiguration — only activates if DataSource class is on classpath + data source URL is configured. If you define your own DataSource bean, it backs off (@ConditionalOnMissingBean). Debugging: spring.autoconfigure.report=true or actuator /actuator/conditions shows what was configured and why.

✓ Strong Answer

Idempotent API design: client sends a unique idempotency key header (Idempotency-Key: UUID). Server processes the request and stores the key + response. If the same key is received again: return the stored response without re-processing. Steps: (1) On first request: check Redis/DB for idempotencyKey. If not found: process, store {idempotencyKey → response, ttl=24h}, return response. (2) On duplicate request: return cached response immediately. TTL = long enough for client retry window (24h for payments). Implementation: Spring interceptor (HandlerInterceptor) or @Aspect to extract header, check cache, short-circuit if found, populate cache after processing. Storage: Redis (ideal — fast O(1), TTL built-in). Uniqueness: client generates UUID v4 per request. Critical: the check + process + store must be atomic or protected against concurrent duplicates. Use Redis SETNX (SET key value NX EX ttl) — if another request with same key is processing, SETNX returns null → return 409 or wait.

✓ Strong Answer

Spring Cache abstraction: @Cacheable (cache result on first call, return cached on subsequent), @CacheEvict (remove from cache on call), @CachePut (always execute and update cache), @Caching (combine multiple). Configuration: CacheManager bean — RedisCacheManager for distributed cache, CaffeineCacheManager for local (in-memory). Strategies: (1) Cache-aside (most common): application checks cache, misses → fetch from DB → populate cache. @Cacheable handles this automatically. (2) Write-through: update DB + cache on every write. @CachePut. (3) Write-behind: update cache, async DB write. Higher performance, risk of data loss. Cache key: by default = method parameters. Custom: @Cacheable(key="#userId"). Condition: @Cacheable(condition="#result != null"). TTL: set per cache name in RedisCacheConfiguration. Pitfalls: (1) Caching mutable data without TTL → stale data forever. (2) Caching null → @Cacheable(unless="#result == null"). (3) Cache stampede on expiry. (4) Serialization: cached objects must be Serializable (Java) or use JSON serialization.

✓ Strong Answer

Java Memory Model (JMM) defines visibility rules between threads. Each thread has its own working copy of variables in CPU registers/caches. Without synchronization, changes by thread A may never be visible to thread B. Happens-before (HB): if action A HB action B, A's effects are visible when B reads. HB relationships: (1) Program order within a thread. (2) Monitor lock: unlock HB all subsequent locks on same monitor. (3) volatile write HB all subsequent volatile reads of same variable. (4) Thread.start() HB all actions in the new thread. (5) Thread.join() HB all actions after the join. volatile guarantees: (1) Reads/writes are to main memory (not CPU cache), (2) Prevents instruction reordering around the volatile access. Does NOT guarantee atomicity for compound operations (check-then-act). Use case: flag variables, publishing singleton instance in DCL. synchronized guarantees: mutual exclusion AND memory visibility (all changes visible after lock release). Use for compound operations.

✓ Strong Answer

GC generations: heap divided into Young (Eden + Survivor S0, S1) and Old (Tenured). Most objects die young (generational hypothesis). Minor GC: collects Young generation, fast (<100ms for most apps). Major/Full GC: collects Old gen, slower. G1GC (Garbage First, default since Java 9): divides heap into equal-sized regions (1-32MB), each region can be Eden/Survivor/Old. G1GC collects the regions with most garbage first (hence "Garbage First"). Concurrent marking (concurrent with application). Stop-the-world: only for Young collection and final marking. Target pause time configurable (-XX:MaxGCPauseMillis=200). Good for heap sizes 4GB-64GB. ZGC (Java 15+, production): mostly concurrent — pause time <1ms regardless of heap size (tested to 16TB). Load barriers: every object read goes through a reference barrier. Trade-off: slightly higher throughput overhead (~5-10%) vs extremely low latency. Use for latency-sensitive services (trading, gaming, payments). Shenandoah: similar goals to ZGC, concurrent compaction, Red Hat maintained. G1GC is the right default; switch to ZGC if P99 latency is affected by GC pauses.

✓ Strong Answer

First-level cache (L1) = the Persistence Context (EntityManager). Scope: single EntityManager instance = single request/transaction (in Spring with @Transactional). Behavior: within a session, calling em.find(User.class, 1L) twice returns the SAME Java object from the L1 cache — only one DB query. Modifications to the entity are tracked (dirty checking) and flushed to DB on commit or explicit flush. Bugs caused by L1 cache: (1) Stale data within session — entity fetched at start of long transaction, DB updated by another process, entity re-read → still returns the cached version. Fix: em.refresh(entity) forces re-read. (2) Massive object graph loading — loading 10K orders in a loop fills the L1 cache with 10K objects and all their relationships → OOM. Fix: use em.clear() periodically in batch processing, or use StatelessSession for bulk operations. (3) Flush timing surprises — Hibernate flushes L1 cache to DB before executing a query (to ensure query sees latest writes). Unintended flush can cause unexpected DB writes mid-method.

✓ Strong Answer

(1) SINGLE_TABLE (default): all subclass data in one table with a discriminator column (dtype). Fast — no JOINs. Polymorphic queries are simple. Downside: subclass-specific columns are nullable (no NOT NULL constraint possible), table gets wide with many subclasses. Use when: performance is priority, subclasses share most columns. (2) TABLE_PER_CLASS: separate table per concrete class with all fields (inherited + own). No JOINs for single-type queries. Polymorphic queries (find all Payments) require UNION ALL across all tables — slow. No single table for the parent type. Use when: rarely need polymorphic queries, subclasses have very different columns. (3) JOINED: parent table + separate table per subclass with FK to parent. Normalized, proper constraints. Polymorphic query: JOIN parent + subclass table. Single-type query: still needs JOIN to parent. Performance: JOIN overhead on every query. Use when: normalization is priority, need NOT NULL constraints on subclass fields, subclasses have many unique columns. (4) @MappedSuperclass: not an inheritance strategy — just maps fields to subclasses without a parent table. No polymorphic queries possible.

✓ Strong Answer

Correct Redis distributed lock: (1) Acquire: SET key uniqueValue NX EX 30 — atomic: set only if key doesn't exist (NX), with 30s TTL (EX). Returns OK on success, null on failure (already locked). The uniqueValue (UUID per lock attempt) is critical — allows only the holder to release. (2) Release: Lua script for atomicity: if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end. Without Lua: GET then DEL is two operations — race condition between them. The uniqueValue prevents accidental release by wrong process (if your process took too long, TTL expired, another process acquired the lock — you should NOT release their lock). (3) TTL extension: if the operation might take longer than the TTL, renew the lock before expiry (Redisson Watchdog does this automatically). Failure modes: (1) Redis crashes after lock acquired — lock released when TTL expires (max TTL delay). (2) Lock holder crashes — same, TTL prevents permanent deadlock. (3) Clock skew in cluster — if Redis primary fails and replica promotes with slightly different state, a lock might be held by two processes (Martin Kleppmann's Redis SETNX critique). For strong guarantees: use Redlock (multi-node consensus) or ZooKeeper.

✓ Strong Answer

CompletableFuture is Java 8's async pipeline abstraction. Key methods: supplyAsync(supplier, executor) — runs in thread pool, returns future. thenApply(fn) — transforms result (like map). thenCompose(fn→CF) — chains to another async operation (like flatMap). thenCombine(other, fn) — combines two independent futures. thenAccept(consumer) — terminal, result has side effect. exceptionally(fn) — handles exception, returns fallback. handle(fn) — handles both result and exception. allOf(cf1, cf2, ...) — waits for all. anyOf — waits for first. Example: fetchUser → fetch orders → compute total, with error handling:

✓ Strong Answer

Deadlock conditions (all 4 must hold): (1) Mutual exclusion (only one thread can hold the resource), (2) Hold and wait (thread holds one resource while waiting for another), (3) No preemption (resources can't be taken away), (4) Circular wait (A waits for B which waits for A). Prevention strategies: (1) Lock ordering — always acquire locks in the same global order across all code paths. If all code acquires lock A before lock B, circular wait is impossible. (2) Lock timeout — tryLock(timeout) with release if timeout expires, then retry. (3) Lock-free algorithms — use atomic operations (AtomicInteger, AtomicReference) and compare-and-swap instead of locks. (4) Use higher-level concurrency utilities (ConcurrentHashMap, BlockingQueue) instead of explicit synchronization. Detection: (1) ThreadMXBean.findDeadlockedThreads() in Java — returns deadlocked thread IDs. (2) JVM thread dump (jstack pid or kill -3) — deadlock section shows which thread holds what and waits for what. (3) JDK Mission Control — live thread analysis.

✓ Strong Answer

Event sourcing: instead of storing current state (UPDATE accounts SET balance = 500), store every state-changing event (MoneyDeposited{amount:100}, MoneyWithdrawn{amount:50}). Current state = result of replaying all events. Benefits: (1) Complete audit trail — every state change is recorded with who, what, when. (2) Temporal queries — "what was the account balance on Dec 31?" (replay events up to that date). (3) Event replay — populate new read models by replaying events. (4) Debugging — reproduce any past state exactly. (5) Natural fit for CQRS — events drive read model projections. Costs: (1) Query complexity — "give me all accounts with balance > 1000" requires replaying all account events. (2) Schema evolution — events must be versioned (event format changes over time). (3) Snapshots needed for long-lived aggregates (don't replay 10 years of events every time). (4) Operational complexity — new pattern for most teams. When to use: financial systems (audit requirement), systems where history matters, systems benefiting from event replay.

✓ Strong Answer

CAP theorem (Brewer, 2000): in a distributed system, under a network partition, you can choose EITHER Consistency (all nodes return the same, up-to-date data) OR Availability (every request gets a response, possibly stale). Partition Tolerance is not a choice — partitions happen in any distributed system. CP systems: prefer consistency, may return errors during partition (ZooKeeper, HBase, etcd). AP systems: prefer availability, may return stale data (Cassandra, DynamoDB, CouchDB). PACELC (Abadi, 2012) extends CAP: Else (when no partition), the trade-off is between Latency and Consistency. PACELC gives 4 categories: PC/EC (consistent always, no latency optimization — etcd), PA/EL (available + low latency — DynamoDB default), PA/EC (available during partition, consistent during normal ops), PC/EL (consistent during partition, low latency during normal ops). Practical: CAP describes failure mode behavior. PACELC describes normal operation behavior. Both matter for system design.

✓ Strong Answer

Idempotency must be end-to-end — if any layer is non-idempotent, the system is non-idempotent. Layers: (1) HTTP API: idempotency key header, check+store as discussed. (2) Kafka producer: enable.idempotence=true prevents duplicate messages per session. Across sessions: application-level message ID in headers, consumer checks before processing. (3) Kafka consumer: check message ID against processed-IDs store (Redis bitmap or DB) before executing. Use message ID as the idempotency key for the DB write. (4) External API calls (payment gateway, SMS): pass the same idempotency key on retry. Most payment gateways (Stripe, Razorpay) support idempotency keys on their API. (5) Database writes: use UPSERT (INSERT ... ON CONFLICT DO NOTHING) with a unique constraint on the natural idempotency key (order ID, payment reference). (6) Scheduled jobs: check if already executed for this schedule window before running. Idempotency store options: Redis (fast, TTL, can expire old keys), PostgreSQL unique constraint (simpler, more durable), Bloom filter (space-efficient, false positives only).

✓ Strong Answer

S - Single Responsibility: a class has one reason to change. Spring example: separate OrderService (business logic) from OrderRepository (data access) from OrderController (HTTP mapping) from OrderMapper (DTO conversion). Violation: service method that queries DB, sends email, and formats a PDF. O - Open-Closed: open for extension, closed for modification. Spring example: use Strategy pattern for payment processing — PaymentProcessor interface, implementations (StripeProcessor, RazorpayProcessor, PayPalProcessor). Adding new provider = new class, no modification to existing code. L - Liskov Substitution: subclass must be usable wherever parent is used. Violation: subclass that throws UnsupportedOperationException on parent's method. Spring: CachingUserRepository extends UserRepository — all parent methods work correctly. I - Interface Segregation: prefer small, specific interfaces over one large interface. Instead of UserService with 20 methods, have UserQueryService, UserCommandService, UserAuthService. D - Dependency Inversion: depend on abstractions, not concretions. Spring's entire dependency injection is DI — inject interfaces, not concrete classes. Makes testing easy (mock the interface).

✓ Strong Answer

Step-by-step: (1) Confirm the symptom: is it sustained high CPU (busy-waiting, infinite loop, hot path) or periodic spikes (GC, scheduled jobs)? Check GC logs first — GC pauses cause CPU spikes. (2) Profiling without code changes: async-profiler (low overhead, safe for production). Flame graph shows exactly which methods consume CPU time. Commands: async-profiler -d 30 -f /tmp/profile.html <PID>. (3) Read the flame graph: wide bars = CPU time. Look for unexpected width in infrastructure code (serialization, reflection, regex compilation, logging). (4) Common culprits: regex Pattern.compile() inside hot loops (fix: static final Pattern), JSON serialization/deserialization (expensive per-call, fix: reuse ObjectMapper), reflection (expensive, fix: method handles or code gen), string concatenation in loops (fix: StringBuilder), logging at DEBUG level in production (fix: isDebugEnabled() guard). (5) JIT compilation: JVM optimizes hot code after ~10K invocations. Ensure JVM has warmed up before benchmarking (use JMH for microbenchmarks).

✓ Strong Answer

Serialization cost breakdown: JSON (Jackson) — human-readable, large payload, ~500ns-2μs per object. MessagePack — binary JSON, smaller payload, 2-3× faster than Jackson. Protocol Buffers (Protobuf) — binary, strongly-typed, ~5-10× faster than JSON, 30-60% smaller payload. Avro — binary + schema registry, good for Kafka. FlatBuffers — zero-copy parsing (access fields without deserializing the full message), fastest for random field access. Thrift — similar to Protobuf, developed at Facebook. For Kafka: Avro + Confluent Schema Registry is the standard (schema evolution support, compact binary). For REST APIs: JSON is fine for most use cases. For high-throughput internal microservice communication (>50K req/sec): Protobuf + gRPC or binary serialization can be a significant win. Jackson optimizations: reuse ObjectMapper (expensive to create), use @JsonIgnoreProperties(ignoreUnknown=true), use InputStream-based parse rather than String-based.

✓ Strong Answer

HikariCP is the de-facto Java DB connection pool (default in Spring Boot). Key settings: maximumPoolSize: max connections to DB. Formula: (core_count × 2) + effective_spindle_count. Typical: 10-20 for SSD-backed DB, larger for spinning disk. Too large: DB overwhelmed with connections + context switches. Too small: connection wait time + throughput ceiling. minimumIdle: min idle connections (set to 0 for cost-sensitive or equals maximumPoolSize for constant throughput). connectionTimeout: max wait to acquire a connection before throwing exception (default 30s — usually too long; set to 2-5s). idleTimeout: how long an idle connection can sit before being closed (default 10min). maxLifetime: max age of a connection before being retired (default 30min — must be less than DB server's wait_timeout). keepaliveTime: interval to send keepalive queries (default disabled — enable if firewall drops idle connections). validationTimeout: time to test connection health on acquisition.

✓ Strong Answer

HTTP caching headers: Cache-Control: public max-age=3600 — browser and CDN cache for 1 hour. Cache-Control: private max-age=3600 — browser cache only (CDN doesn't cache). Cache-Control: no-cache — must revalidate with server on each use (uses ETag). Cache-Control: no-store — never cache. ETag: server generates hash of response content (MD5 of body or version field). Client sends If-None-Match: etag header on subsequent request. Server returns 304 Not Modified if content unchanged (no body = fast). Last-Modified + If-Modified-Since: same concept but time-based (less precise). Stale-while-revalidate: serve stale content immediately while refreshing in background. Vary header: tells CDN that the cache key includes other headers (e.g., Vary: Accept-Language caches separate copies per language). Strategy: static assets (JS, CSS, images) → long max-age + content hash in filename. Dynamic API responses → short max-age + ETag. Personalized responses → private or no-store.

✓ Strong Answer

SQL injection prevention: (1) Parameterized queries / prepared statements: JDBC PreparedStatement, JPA named/positional parameters, Spring Data JPA @Query with :param binding. NEVER string concatenation for SQL. (2) ORM use: JPA/Hibernate by default uses parameterized queries for all generated SQL. (3) Spring Data JPA native queries: still use @Query("... WHERE id = :id", nativeQuery=true) with @Param("id") — never string format. Other injection types: (1) JPQL injection: same as SQL — never concatenate user input into JPQL strings. (2) Log injection: if user input appears in logs, newlines can inject fake log entries. Fix: sanitize or encode newlines in logged user input. (3) OS command injection: never pass user input to Runtime.exec() or ProcessBuilder without strict validation. (4) XML/XPath injection: use parameterized XPath. (5) LDAP injection: use LDAP escape on all input. Input validation: whitelist approach (validate input matches expected format) is better than blacklist (block known bad). Spring Validation: @Valid + @NotNull + @Pattern for request DTOs.

✓ Strong Answer

OAuth2 roles: Resource Owner (user), Client (your app), Authorization Server (issues tokens), Resource Server (API). Flow for microservices: (1) User authenticates with Auth Server (e.g., Keycloak, Auth0, AWS Cognito, or custom). (2) Auth Server issues Access Token (JWT, short-lived 15-30min) + Refresh Token (opaque or JWT, long-lived 7-30 days, stored server-side). (3) Client includes Access Token in Authorization: Bearer header on every request. (4) Each microservice validates JWT: (a) Verify signature using Auth Server's public key (cached, fetched via JWKS endpoint). (b) Check expiry (exp claim). (c) Check audience (aud claim) — token must be intended for this service. (d) Check scopes/roles. No network call to Auth Server per request (stateless validation). JWT contents: sub (userId), iss (issuer), exp (expiry), iat (issued at), roles, tenantId. Do NOT put sensitive data in JWT — it's base64 encoded (not encrypted) so visible to anyone with the token.

✓ Strong Answer

Resource naming: nouns not verbs (/users not /getUsers). Plural (/users not /user). Hierarchy for sub-resources (/users/{id}/orders). HTTP methods: GET (read, idempotent, cacheable), POST (create, not idempotent), PUT (replace entire resource, idempotent), PATCH (partial update), DELETE (idempotent). Status codes: 200 OK, 201 Created (with Location header), 204 No Content, 400 Bad Request (validation), 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Entity (semantic validation), 429 Too Many Requests, 500 Internal Server Error. Pagination: cursor-based (next token from last item ID) for large datasets — page number pagination breaks on data changes. Filtering: query params (?status=active&category=electronics). Sorting: ?sort=createdAt&order=desc. Versioning: URL (/v1/) for major breaking changes. Idempotency: Idempotency-Key header for POST. HATEOAS: links in response showing related actions (good for hypermedia APIs, optional for most). Error responses: consistent schema {code, message, details[], traceId}.

✓ Strong Answer

gRPC advantages: (1) Binary (Protobuf) serialization: 5-10× faster, 30-60% smaller than JSON. (2) Strongly-typed schema (proto files): compile-time contract, auto-generated client code in 11+ languages. (3) HTTP/2: multiplexed streams (multiple requests/responses on one connection), header compression, full-duplex streaming. (4) Streaming: unary (request-response like REST), server streaming, client streaming, bidirectional streaming. (5) Interceptors: server and client interceptors for cross-cutting concerns (auth, logging, tracing). Disadvantages: (1) Not human-readable (binary) — harder to debug with curl, browser. (2) Limited browser support — gRPC-Web is a workaround but not native gRPC. (3) Schema coupling — both sides need proto files, schema evolution requires backward compatibility. (4) Learning curve — protobuf syntax, code gen setup. Use gRPC for: internal microservice-to-microservice communication where performance matters, polyglot services (Java calling Go), streaming use cases (real-time data), mobile apps (smaller payload = less battery/data). Use REST for: public APIs (browser accessible), simple integrations, when JSON readability matters.

✓ Strong Answer

Stages: (1) Code commit → trigger CI. (2) Build: mvn package or gradle build. (3) Unit tests: JUnit 5, Mockito. Fail fast. (4) Static analysis: Checkstyle (code style), SpotBugs (bug patterns), PMD, SonarQube (code smells, coverage gate). Fail if coverage < threshold or critical issues found. (5) Integration tests: TestContainers (real DB, Kafka in Docker). (6) Docker build: multi-stage Dockerfile (build in JDK image, run in JRE image — reduces image size 60%). Tag with git commit SHA. Push to ECR/GCR. (7) Security scanning: Trivy or Snyk scans the Docker image for known CVEs. Fail on CRITICAL CVEs. (8) Deploy to staging: Helm upgrade or ArgoCD GitOps. Run smoke tests. (9) Performance/load test in staging: k6 or Gatling — compare P99 vs baseline. Fail if regression > 10%. (10) Deploy to production: blue-green or canary. Automated rollback if error rate spikes.

✓ Strong Answer

Production Dockerfile: (1) Multi-stage build: stage 1 uses JDK to build, stage 2 uses JRE (or distroless) to run — reduces image size from ~600MB to ~200MB. (2) Non-root user: run as non-root (USER 1001) — container escape vulnerabilities are less impactful. (3) Layer caching: COPY pom.xml + mvn dependency:go-offline before COPY src/ — dependencies cached unless pom.xml changes, speeds up CI. (4) JVM container awareness: JDK 10+ auto-detects container CPU and memory limits. Set -XX:MaxRAMPercentage=75 (uses 75% of container memory, leaves room for off-heap, metaspace, thread stacks). (5) Health check: HEALTHCHECK CMD curl --fail http://localhost:8080/actuator/health/liveness. (6) Signals: use exec form for ENTRYPOINT: ENTRYPOINT ["java", "-jar", "app.jar"] — shell form swallows SIGTERM, preventing graceful shutdown. (7) Read-only filesystem: consider VOLUME for /tmp if app writes temp files.

✓ Strong Answer

Structured design review process: (1) Pre-work: circulate a written design doc (1-pager or RFC) 48 hours before the meeting. Forces proposer to articulate trade-offs clearly. Reviewers have time to think, reducing hot-take reactions. (2) Meeting structure: 10 min: proposer presents design — no interruptions. 20 min: clarifying questions (not critique yet). 20 min: structured critique. Each concern must include: what could go wrong, how likely, and what's the impact. (3) Decision criteria: agree upfront on what we're optimizing for (latency vs simplicity vs cost vs team familiarity). Disagreements often resolve when decision criteria are explicit. (4) Disagree and commit: once decision is made, everyone implements it together — no passive resistance. (5) Reversibility: prefer reversible decisions for uncertainty. "Let's try approach A for 2 weeks and review" reduces resistance.

✓ Strong Answer

Structured mentorship: (1) Understand where they are: pair program with them for 2 hours on their current work — observe where they get stuck, what they Google, what they don't know they don't know. This tells you more than any conversation. (2) Set explicit growth goals: not "get better at backend" but "design a complete microservice independently by Q2, including data model, API design, and deployment." (3) Stretch assignments: assign work at the edge of their comfort zone — not too easy (no growth) not too hard (frustration). Be available but don't solve it for them. (4) Teach through questions: Socratic method. "What have you tried? What would happen if X? How would you verify that?" Instead of "Here's the answer." (5) Code review as teaching: explain WHY in every review comment. "This causes N+1 queries because Hibernate lazy-loads the collection — here's how to fix with JOIN FETCH." Not just "change this." (6) Technical talks: encourage presenting their work to the team — accelerates growth and builds confidence.

✓ Strong Answer

Framework: (1) Quantify the debt. Don't say "our codebase is a mess." Say "the missing test coverage on OrderService caused 3 production incidents this quarter costing 40 engineer-hours of incident response." The debt is worth paying if paying it costs less than keeping it. (2) Prioritize by: severity of impact (incidents, slowdown, security), blast radius (how many features does this block), cost to fix (1 week vs 6 months). (3) The Boy Scout Rule — fix tech debt in the code you're already touching. Allocate 20% of every sprint to debt without a separate "debt sprint" (debt sprints get cut when roadmap pressure arrives). (4) Make debt visible — maintain a tech debt register with estimated cost per item. Review quarterly with EM and product. (5) Never let perfect be the enemy of good — "we need to refactor everything before shipping X" is usually wrong. Ship X with a plan to refactor the specific parts you touched.

✓ Strong Answer

Structured approach: (1) Observe and document specific behaviors, not personality judgments. Not "they're arrogant" but "in last 3 meetings, they talked over two colleagues who were mid-sentence, including twice when the colleague had a critical concern they hadn't addressed." (2) Private, candid conversation: "I've observed X specific behavior. What's your perspective?" Listen before prescribing — sometimes there's context you don't have (conflict with a specific team member, personal stress). (3) State the impact: "When this happens, two effects: first, your colleagues stop contributing ideas in meetings, second, your reputation as someone who builds others is hurt, which affects how I can advocate for your promotion." (4) Agree on specific behavior change: "In the next 3 sprints, I'd like to see you solicit at least one other opinion before presenting your recommendation, and give each speaker 2 full minutes before responding." Concrete, observable. (5) Follow up regularly — don't raise it once and disappear. (6) Acknowledge improvement explicitly when it happens.

✓ Strong Answer

STAR format: Situation — "During a critical project redesign, a senior architect insisted on a microservices-first approach. I believed a modular monolith was more appropriate given our team size (6 engineers) and the 3-month timeline." Task — "I was the tech lead and responsible for the delivery timeline and architecture." Action — "I prepared a 2-page technical analysis: both approaches side by side on: delivery timeline (modular monolith 3 months vs microservices 5-6 months for initial scope), operational complexity (monitoring and debugging 8 services with 3 engineers is unsustainable), and migration path (modular monolith → microservices when warranted is well-documented). I shared this before the meeting, asked for 30 min to walk through it together, and explicitly asked: what concern would the microservices architecture solve that I'm missing?" Result — "We agreed on a modular monolith with clean service boundaries that could be extracted later. Shipped in 3.5 months. 12 months later, extracted 2 services where the scale warranted it."

✓ Strong Answer

STAR: Situation — "During a Black Friday weekend, our payment service was reporting 3% elevated error rates. Investigation showed the root cause was a memory leak in a shared authentication library maintained by the platform team, not our code." Task — "This wasn't my team's library, but it was our service that was degraded and our users who were affected." Action — "I (1) Immediately informed the platform team lead with a detailed diagnosis — here's the heap dump, here's the thread that's leaking, here's the reproduction steps. (2) While they were investigating their code, I implemented a temporary mitigation: a periodic JVM restart of the auth service (ugly but effective in 30 min). (3) Worked with the platform team to test their fix and validate in staging. (4) Wrote a postmortem on behalf of both teams identifying that this class of library had no memory testing in CI — got a new CI rule added." Result — "Error rate returned to baseline within 2 hours. The platform team lead specifically thanked me in the post-incident review for the quality of the diagnosis and the proactive mitigation."

✓ Strong Answer

STAR: Situation — "Led the redesign of our real-time fraud detection system, which needed to process 200K transactions/day with <100ms decision latency, replacing a rule-only system with an ML-enhanced approach." Task — "I was tech lead for a team of 4 engineers with 4 months and a hard deadline (regulatory review)." Action — "(1) Decomposition: broke into 5 independent tracks (feature store, real-time scoring API, model serving infrastructure, rule engine integration, monitoring). Each had a clear owner and 2-week milestones. (2) Dependency analysis: identified that the feature store was the critical path — all other tracks depended on it. Staffed it with the strongest engineer. (3) Risk register: listed top 5 technical unknowns, each with a spike (2-day prototype) to validate assumptions. (4) Weekly demos to stakeholders — kept everyone aligned and surfaced scope creep early. (5) Integration testing at 4 weeks, 8 weeks, and 12 weeks — not just at the end." Result — "Delivered on time. Fraud detection improved from 78% to 92% catch rate. False positive rate reduced from 0.8% to 0.1%. No production incidents in first 90 days."

✓ Strong Answer

STAR: Situation — "Joined a team where production incidents were common (avg 2/week), postmortems were blame-y, and engineers were afraid to try new things. The culture was 'don't break anything' rather than 'learn and improve.'". Task — "As senior engineer (not EM), I wanted to change this without formal authority." Action — "(1) Started with the postmortem format — introduced blameless postmortem template (timeline, contributing factors, 5 Whys), ran the first one myself to model the behavior. (2) Added 'What went well' section — if you only discuss failures, people think the system is broken. (3) Proposed monitoring improvements that would catch issues before they became incidents — framed as 'we should know before customers do,' not as criticism of current state. (4) Introduced a weekly 'learning share' — 15 min Fridays where anyone could share something they learned, including a mistake and its lesson. No judgment. (5) Publicly celebrated near-misses caught by monitoring — shifted perception that preventing an incident was as valuable as shipping a feature." Result — "Over 6 months: incidents dropped from 2/week to 0.5/week. Three engineers who had been very quiet started proposing architectural improvements. The EM thanked me in a skip-level."

✓ Strong Answer

STAR: Situation — "Two weeks before launch, we discovered a performance issue in our payment processing service: under load, P99 latency was 3× our SLA. Fixing it required a data model change — minimum 3 more weeks." Task — "I needed to communicate this to the product team, business stakeholders, and the engineering director — the delay would affect a marketing campaign that was already scheduled and announced." Action — "(1) Assessed the situation fully before scheduling the meeting — what's the root cause, what are the options, what's the fastest path. Don't walk into the room with only a problem; bring options. (2) Structured the message: what happened, what the impact is, what our options are (launch with a degraded SLA and fix it post-launch, delay 3 weeks and launch correctly, descope to a subset with guaranteed performance). (3) Made a recommendation: delay 3 weeks with the justification that launching with known performance issues on a payment service creates trust problems that are harder to recover from than a 3-week delay. (4) Set a recovery milestone: daily status update for the next 3 weeks." Result — "Stakeholders chose the 3-week delay based on our recommendation. Post-launch, the service performed above SLA. Zero performance-related issues in the first 90 days."

✓ Strong Answer

Framework: (1) Lead with business impact, not technical detail. Not "we need to move from a monolith to microservices" but "this change will let the product team ship features 40% faster and reduce production incidents by 60%." (2) Use analogies. Monolith vs microservices: "right now all our code is in one kitchen — if the fridge breaks, no one can cook. With microservices, each team has their own kitchen." (3) Risk and cost framing. Every technical decision has business consequences: "option A costs ₹20L to build but reduces maintenance by ₹8L/year — breaks even in 2.5 years." (4) Decision, not options. Don't dump all the options — pre-analyze and come with a recommendation. "Here are the 3 options. I recommend option 2. Here's why options 1 and 3 are inferior." (5) Address their specific concern. Stakeholders care about: timeline, budget, risk, competitive advantage, compliance. Know which concern dominates for your audience.

✓ Strong Answer

Structured approach: (1) Identify signal sources. Hacker News and Twitter/X for early signal. GOTO Conferences, InfoQ, QCon for practitioner depth. SpringOne, KubeCon, Kafka Summit for specific ecosystems. "The Morning Paper" (CS papers). (2) Build, don't just read. Reading about Kafka KRaft is different from migrating a cluster. Every major concept I learn gets a working prototype — even 100 lines in a GitHub repo with a README documenting what I learned. (3) Teach to solidify. Write a blog post or give a team talk on what you learned. Teaching forces gaps in understanding to surface. (4) Prioritize by relevance. Not every new technology deserves attention. Filter by: Is it solving a problem I have? Is it being adopted by production systems I respect (Netflix, Google, Cloudflare)? Is it backed by a sustainable project (Apache, CNCF, major company)? (5) Allocate explicit time. 2 hours/week minimum for learning. Block it in the calendar — it gets pushed out by sprint work otherwise.

✓ Strong Answer

STAR: Situation — "I deployed a database migration that I'd tested in staging, but staging had a different data distribution than production. In production, a query that ran in 200ms in staging took 45 seconds — table lock held for the duration, causing cascading failures across 3 services." Task — "The deployment was mine, the incident was mine to own and resolve." Action — "(1) Immediately identified the root cause via slow query logs (2 minutes). (2) Rolled back the migration (complex — needed to reverse the schema change while preserving new data written in the gap). (3) Communicated to stakeholders every 10 minutes with status. (4) Recovered service in 35 minutes. (5) Postmortem: root cause was data distribution mismatch between staging and prod. I had tested the query on a representative data sample in staging but not on the exact production schema configuration (a specific index configuration that only existed in production — created for a different feature). Action items: shadow migration testing on production (readonly), add production data sampling to staging, add query execution plan to deployment checklist." Result — "Zero recurrence of this class of issue for 18 months. The shadow migration process I designed was adopted by two other teams."

✓ Strong Answer

Orchestration: a central orchestrator (process manager, workflow engine) explicitly calls each service in sequence, tracks state, and handles failures. Pros: business flow is visible in one place, easy to monitor, explicit error handling. Cons: orchestrator is a new component, potential bottleneck, tight coupling to all services. Tools: Netflix Conductor, Cadence/Temporal, Apache Camel. Choreography: each service publishes events and reacts to events from others. No central coordinator. Pros: loose coupling, services are independently deployable, easy to add new participants. Cons: business flow is implicit (distributed across event handlers), hard to understand the full flow, debugging is harder. Use orchestration for: complex multi-step business processes (order fulfillment, loan approval) where visibility and error handling matter. Use choreography for: simple linear flows, systems where services are owned by different teams and you want loose coupling.

✓ Strong Answer

Three main models: (1) Silo (database-per-tenant): strongest isolation, simplest security model. Each tenant has their own DB instance. Pros: no risk of cross-tenant data leaks, easy per-tenant backup and restore, can be on different DB versions. Cons: expensive (100 tenants = 100 DB instances), complex operations, underutilized resources. Best for: enterprise/regulated tenants with compliance requirements. (2) Bridge (schema-per-tenant in one DB): one DB, separate schema per tenant. Better resource utilization than silo. Pros: easier to manage than silo, still good isolation. Cons: schema migrations must run across all schemas, still complex. (3) Pool (shared schema): all tenants in the same tables with tenant_id column. Pros: lowest cost, simplest operations, easy to add tenants. Cons: must rigorously enforce tenant_id filtering everywhere (OWASP risk), harder to isolate performance (noisy neighbor), harder to do per-tenant data operations. Hybrid: pool for small/free tenants, silo for enterprise paying tenants.

✓ Strong Answer

Named after the strangler fig tree that grows around a host tree and eventually replaces it. Applied to software modernization: (1) Put a facade/proxy in front of the legacy system. Initially, all traffic passes through to legacy. (2) Identify a bounded context to modernize. Build the new service. (3) Route that specific traffic through the facade to the new service. Legacy still handles everything else. (4) Iterate: more and more functionality migrates to new services. (5) Eventually, the legacy system handles no traffic and is decommissioned. The legacy system is "strangled" incrementally — no big-bang rewrite. Key implementation: the facade must be transparent to clients. URL path routing (API Gateway) or DNS-level routing can direct specific endpoints to old vs new. Feature flags enable gradual rollout. Data migration can happen incrementally alongside code migration.

✓ Strong Answer

Traditional I/O path (4 copies): disk → kernel buffer → user space buffer → kernel socket buffer → NIC. Each copy is CPU + memory bandwidth overhead. Zero-copy techniques: (1) sendfile() syscall (Linux): disk → kernel buffer → NIC. Skips user space entirely. Used by Kafka for log segment serving — this is why Kafka is so fast at consumer reads. (2) mmap(): map file directly into process address space. Read file as memory array without explicit read() calls. Useful for random access patterns. (3) Direct I/O (O_DIRECT): bypass kernel page cache, write directly from user buffer to disk. Used by databases (PostgreSQL, MySQL) that manage their own cache. (4) Java NIO: ByteBuffer.allocateDirect() → off-heap memory, can be used with FileChannel.transferTo() (wrapper around sendfile). Java zero-copy for file serving. (5) io_uring (Linux 5.1+): fully async I/O interface that minimizes syscall overhead — being adopted by high-performance Java servers (Netty, Vertx).

✓ Strong Answer

Little's Law: L = λW. L = average number of items in the system. λ = average arrival rate (throughput). W = average time an item spends in the system (latency). Derived: W = L/λ. Applications: (1) If you have 100 concurrent requests (L), throughput of 50 req/sec (λ), then average latency W = 100/50 = 2 seconds. If your target latency is 500ms, you need λ = L/W = 100/0.5 = 200 req/sec capacity. (2) Thread pool sizing: if each request takes W=50ms and you want to handle λ=1000 req/sec, you need L = λ × W = 1000 × 0.05 = 50 threads minimum. (3) Queue depth: if consumers process at 100/sec and queue depth is 1000, the wait time before processing = 1000/100 = 10 seconds. (4) DB connection pool: if each query takes W=10ms and you have 50 queries/sec (λ), you need L = 50 × 0.01 = 0.5 connections on average. But P99 might need 5× → 3-5 connections minimum.

✓ Strong Answer

RBAC (Role-Based Access Control): permissions assigned to roles, roles assigned to users. Simple, auditable. Example: ROLE_ADMIN → can delete users. Spring Security: @PreAuthorize("hasRole('ADMIN')"). Works well for: relatively static permission sets with clear role boundaries. Limitation: role explosion — 50 roles to cover all combinations. ABAC (Attribute-Based Access Control): permissions based on attributes of the user, resource, and environment. Example: user.department == resource.department AND time.hour BETWEEN 9 AND 17 AND resource.classification == 'INTERNAL'. Very flexible, expressive. Limitation: complex to audit, complex to implement correctly. PBAC (Policy-Based Access Control): external policy engine evaluates policies. OPA (Open Policy Agent), Casbin. Policies are code (Rego language in OPA), version-controlled, testable. Separates authorization logic from application code. Best of both worlds: expressive like ABAC, auditable like RBAC. Use PBAC when authorization logic is complex enough to warrant a separate service.

✓ Strong Answer

STAR: Situation — "Our team was about to adopt a new service mesh (Istio) as a company-wide standard. I believed the operational complexity was too high for our team size (12 engineers) and would slow us down for 6 months without proportional benefit." Task — "I had no authority to block the decision — it was being driven by the platform team. But I could influence it." Action — "(1) Did the homework first: ran Istio in our dev environment for 2 weeks. Documented specific pain points: 200MB overhead per pod × 40 pods = 8GB RAM waste, 2 engineers spending 20% of time on Istio config, sidecar injection errors during deployments. (2) Found allies: talked to 3 other team leads who had similar concerns privately. We agreed to raise our concerns together. (3) Proposed an alternative: Linkerd has 80% of Istio's value at 20% of the complexity. Presented a side-by-side comparison. (4) Offered a pilot: proposed a 6-week pilot on one service to compare operational overhead. (5) Escalated to data, not hierarchy: presented the analysis in the platform team's quarterly review — metrics, not opinions." Result — "The pilot was approved. Linkerd was chosen over Istio company-wide based on 6 weeks of real data."

✓ Strong Answer

STAR: Situation — "Our staging environment had 40% test flakiness (tests that randomly fail with no code change). Engineers were ignoring red CI builds and just re-running until they went green. This was masking real failures." Task — "Nobody had asked me to fix this. It wasn't in any sprint. But it was clearly undermining our deployment confidence." Action — "(1) Started by quantifying the problem: wrote a script to analyze CI results for the past 3 months — documented 247 flaky tests, estimated 15 hours of engineer time wasted per week on re-runs. (2) Identified the top 20 flaky tests (Pareto: 20 tests caused 80% of flakiness). Root causes: timing-dependent tests (Thread.sleep), tests sharing state through static variables, tests making real network calls to unstable test environments. (3) Fixed the top 20 over 3 evenings. Used Awaitility for async assertions instead of Thread.sleep, added proper test isolation (reset state in @BeforeEach), used WireMock for external API calls. (4) Added flakiness detection to CI: if a test fails then passes on retry, it's marked as flaky and reported. (5) Documented the pattern library so others could fix remaining tests." Result — "Flakiness dropped from 40% to 3%. Engineers started trusting CI again. Deploy confidence improved. The EM mentioned it in my performance review unprompted."

✓ Strong Answer

STAR: Situation — "In my mid-year review, my EM told me: 'Your technical quality is excellent, but your peers find it hard to voice their ideas in design meetings when you're present. Two people have mentioned they feel their ideas get dismissed.'". Task — "This was hard to hear because I thought I was being helpful by analyzing ideas quickly and pointing out flaws." Action — "(1) Didn't defend. Asked: 'Can you give me a specific example so I understand what the behavior looks like?' Got two specific examples. (2) Spent a week observing my own meeting behavior — realized I was responding to every idea with the first critique that came to mind, before the person had fully explained it. (3) Implemented a specific rule: for the next month, I would not respond to any idea in the first 2 minutes. I would ask at least one clarifying question before critiquing. (4) Explicitly invited quieter team members: 'Priya, I haven't heard your take on this — what do you think?' (5) After 4 weeks, asked my EM for feedback on whether the behavior had changed." Result — "My EM said the change was noticeable within 2 meetings. Three months later, a peer who had apparently given the original feedback told me directly that design meetings felt more collaborative."

✓ Strong Answer

Spring Security uses a servlet FilterChain. SecurityFilterChain is a list of security filters applied to every request. Key filters in order: ChannelProcessingFilter (HTTPS redirect), SecurityContextPersistenceFilter (loads SecurityContext from session), UsernamePasswordAuthenticationFilter (processes login form), BasicAuthenticationFilter (processes Authorization: Basic header), BearerTokenAuthenticationFilter (processes JWT/OAuth2 Bearer tokens), ExceptionTranslationFilter (catches auth exceptions, redirects to login or returns 401/403), FilterSecurityInterceptor (access control decisions). Authentication flow: filter extracts credentials → AuthenticationManager.authenticate() → AuthenticationProvider (e.g., DaoAuthenticationProvider for DB, JwtAuthenticationProvider for tokens) → returns Authentication object → stored in SecurityContextHolder. Authorization: @PreAuthorize / @PostAuthorize uses SpEL expressions evaluated by MethodSecurityInterceptor. Access control decisions made by AccessDecisionManager. Customization: SecurityFilterChain @Bean with HttpSecurity configuration. Multiple chains: order matters (higher precedence = lower @Order number). URL-based config: .requestMatchers("/api/**").authenticated(). Method security: @EnableMethodSecurity on config class.

✓ Strong Answer

End-to-end exactly-once (Kafka → PostgreSQL): Kafka's exactly-once is within the Kafka broker. The DB write is NOT part of the Kafka transaction. Solution: make the DB write idempotent using the Kafka message's metadata as the idempotency key. (1) Each Kafka message has: topic + partition + offset — this is a globally unique identifier. (2) In the DB, create a processed_messages table: (topic, partition, offset, processed_at) with UNIQUE constraint on (topic, partition, offset). (3) Consumer logic: BEGIN DB transaction; INSERT INTO processed_messages (topic, partition, offset) — if UNIQUE violation, this is a duplicate → ROLLBACK + return; do the business operation; COMMIT. (4) Disable Kafka auto-commit: enable.auto.commit=false. (5) Commit Kafka offset AFTER DB transaction commits. If DB commit fails, Kafka offset is not committed → message is reprocessed → UNIQUE violation detected → treated as duplicate. This gives exactly-once DB writes even with at-least-once Kafka delivery.

✓ Strong Answer

Time-series characteristics: high write volume (sensor data, metrics, logs), recent data is hot (most queries hit recent data), data naturally partitioned by time, often aggregated (avg, sum, percentile over time windows), old data rarely queried and can be compressed/archived. Storage strategies: (1) PostgreSQL + TimescaleDB: transparent time-based partitioning (hypertables), automatic chunk management, native compression for old chunks (10-20× compression ratio), full SQL. Best for teams already on PostgreSQL. (2) InfluxDB: purpose-built TSDb, line protocol for ingest, InfluxQL/Flux for queries, retention policies for auto-deletion. Best for metrics/monitoring. (3) Apache Parquet + S3 + Athena/ClickHouse: columnar storage for offline analytics. Very cheap for historical queries. (4) Cassandra with time-based partition keys: good for very high write throughput with time-range reads per entity. Schema design: partition by (sensor_id, date_bucket) — keeps each partition manageable. Query patterns: time range by sensor, downsampling (avg per hour from per-minute data), anomaly detection (values 3σ from rolling mean).

✓ Strong Answer

Actor model: computation unit (actor) has private state + mailbox. Actors communicate ONLY by sending messages. No shared state → no locks, no data races by design. Actor processes one message at a time (sequential within an actor) but actors run concurrently. Properties: location transparency (actor reference works whether local or remote), fault tolerance (actor hierarchy — parent supervises children, restarts on failure), backpressure (bounded mailbox). Akka (Java/Scala): mature actor framework. Akka Typed (current): message types are explicit in the actor definition. Use Akka when: (1) Building highly concurrent, distributed, fault-tolerant systems. (2) Location transparency needed (local and remote actors are the same). (3) Massive concurrency (100K+ actors is normal). Virtual threads (Java 21): OS thread-like mental model, but JVM manages thousands of virtual threads on OS threads. Blocking I/O suspends the virtual thread, not the OS thread. Use virtual threads when: you have lots of I/O-bound work, want blocking code style (no callbacks/Futures), and are migrating from thread-per-request model. Much simpler than actors for typical web service concurrency.

✓ Strong Answer

Elasticsearch architecture: inverted index at its core. An inverted index maps each term → list of documents containing it (posting list). Analysis pipeline: text → tokenizer (splits by whitespace/punctuation) → token filters (lowercase, stemming, stop words) → indexed terms. Query types: (1) match: full-text search with analysis, relevance scoring (TF-IDF or BM25). (2) term: exact match, no analysis (for keywords, IDs). (3) bool: combine must/should/must_not/filter clauses. (4) range: numeric/date range. (5) aggregations: GROUP BY equivalent (terms, histogram, percentile). Relevance scoring: BM25 (default) scores documents by term frequency × inverse document frequency. Cluster: shards (primary + replica) distributed across nodes. Documents in an index are sharded by routing key (default: doc ID hash). Near-real-time: writes go to in-memory buffer → become searchable after refresh interval (default 1 second). PostgreSQL full-text: tsvector type stores pre-computed lexemes, tsquery for search, GIN index on tsvector. Supports ranking (ts_rank). Good enough for: single-language search, simple relevance needs, small to medium data size, when you want to avoid a separate search cluster.

✓ Strong Answer

Core requirements: upload photos, follow users, view personalized feed, like/comment. Scale: 1B users, 100M photos/day upload, 500M DAU viewing feed. (1) Photo upload: presigned S3 URL for direct client → S3 upload (no server in the middle). After upload complete, client notifies API. Async processing pipeline (Kafka event → workers): generate thumbnails (3-5 sizes), extract metadata, run content moderation. CDN (CloudFront) in front of S3 for reads — photos served at edge, origin is S3. (2) Social graph: follow relationships stored in a graph DB or Redis set. (3) Feed generation — two models: Pull (fanout on read): when user opens app, query all followed users' recent posts, merge, rank. Simple to write, expensive at read time for users with many followees. Push (fanout on write): when user posts, write to every follower's feed timeline. Fast read, expensive write for celebrities. Hybrid: fanout on write for regular users (<5K followers), fanout on read for celebrities (Taylor Swift's posts are not pre-written to 100M follower feeds). (4) Feed storage: Redis sorted set per user (sorted by post timestamp), with TTL.

✓ Strong Answer

Core challenge: concurrent edits by multiple users must converge to the same document state. Two approaches: (1) Operational Transformation (OT): used by Google Docs. Operations (insert/delete at position) are transformed against concurrent operations to ensure commutativity. Complex algorithm, requires a centralized server to sequence operations. (2) CRDTs (Conflict-free Replicated Data Types): data structure that allows concurrent edits to merge automatically without conflict. Used by Figma, Notion (Yjs library). More amenable to P2P and offline scenarios. Architecture with OT: (1) WebSocket server for real-time connections. (2) Each client sends operations (insert "A" at position 5). (3) Server maintains authoritative document state and operation history. (4) Transform incoming operations against concurrent operations already applied. (5) Broadcast transformed operations to all connected clients. (6) Persistence: Kafka event for every operation → consumer writes to PostgreSQL (operation log) + Redis (document snapshot for fast load). Operational complexity: websocket server is stateful (connected users) — use sticky sessions (user always connects to same server for a document) or distributed session store.

✓ Strong Answer

GitOps principles: (1) Declarative: desired system state fully described in Git (Helm charts, Kustomize manifests, raw YAML). (2) Versioned and immutable: Git provides audit log, rollback = revert commit. (3) Pulled automatically: the agent (ArgoCD, Flux) in the cluster continuously compares desired state (Git) vs actual state (cluster) and reconciles. (4) Continuously reconciled: drift (manual kubectl changes) is detected and corrected automatically. Traditional CI/CD: CI pipeline runs kubectl apply (push model — CI has cluster credentials, pushes changes). GitOps: CI builds and pushes Docker image, updates image tag in Git manifest, ArgoCD/Flux detects change and applies (pull model — cluster has credentials, pulls from Git). Security benefit: no external system needs cluster access. ArgoCD vs Flux: ArgoCD: rich UI, multi-cluster management, app-of-apps pattern, good for ops teams managing many clusters. Flux: more minimal, Kubernetes-native (no external UI), GitOps Toolkit components composable, good for teams embedding GitOps into their Kubernetes workflow. Both are CNCF projects.

✓ Strong Answer

Java 21 (LTS, September 2023) key features: (1) Virtual Threads (JEP 444 — production): lightweight threads managed by JVM. One-to-many mapping to OS threads. Blocking I/O suspends the virtual thread, parks the carrier thread for other virtual threads to use. Enables thread-per-request at massive scale. Spring Boot 3.2 auto-configures virtual threads for Tomcat. (2) Structured Concurrency (JEP 453 — preview): treat groups of subtasks as a unit. StructuredTaskScope: if any subtask fails, cancel the others. Improves cancellation and error handling. (3) Sequenced Collections (JEP 431): adds first()/last() methods to List, Deque — no more workarounds to get the last element. (4) Record Patterns (JEP 440): pattern matching in switch for records. (5) Pattern Matching for switch (JEP 441 — production): switch on type with binding. (6) String Templates (JEP 430 — preview): interpolated strings STR."Hello \{name}". (7) Unnamed Classes/Instance Main Methods (JEP 445 — preview): simplifies learning Java. Key migration path: Spring Boot 3.2 + Java 21 = virtual threads enabled with spring.threads.virtual.enabled=true — instant concurrency improvement for I/O-bound services.

✓ Strong Answer

OSIV (Open Session in View): Spring's default behavior (spring.jpa.open-in-view=true by default) — the Hibernate EntityManager is opened at the start of the HTTP request (in the Servlet filter) and closed at the end, AFTER the controller and view have rendered. This allows lazy loading of relationships in the view layer (Thymeleaf templates, JSON serialization). Problem: (1) Lazy loading happens OUTSIDE the @Transactional boundary — a new connection is borrowed from the pool in the view layer. This can exhaust the connection pool. (2) Unpredictable DB queries triggered by serialization — Jackson serializing an entity may trigger N+1 queries on lazy relationships. Hard to predict and debug. (3) Long connection hold time — connection is held for the entire request including view rendering time. (4) Business logic in the view layer — lazy loading in templates is a layering violation. Fix: (1) Disable OSIV (spring.jpa.open-in-view=false) — forces you to load everything in the @Transactional service layer. (2) Use DTOs (Data Transfer Objects) to decouple the entity graph from the API response. (3) Use @EntityGraph or JOIN FETCH to load needed relationships eagerly in the service layer.

✓ Strong Answer

At 1M events/sec, every layer must be designed for throughput: (1) Ingest layer: UDP instead of TCP for non-critical logging (no connection overhead, fire-and-forget) OR HTTP/2 with batched payloads (100 events per request → 10K RPS instead of 1M RPS). (2) Kafka as the buffer: Kafka can handle 1M+ events/sec with proper tuning. Producer batching: batch.size=100KB, linger.ms=5 (wait 5ms to accumulate a batch). Compression: compression.type=lz4 (fastest with good ratio). Async sends (fire and forget or acks=1 for speed). Multiple partitions for parallelism (num.partitions=100 for 1M/sec with 100 consumers). (3) Consumer / storage layer: batch consumption (poll 1000 events), batch insert to storage. Storage options: ClickHouse (columnar, optimized for append + analytics, handles 100K rows/insert easily), Apache Parquet on S3 (cheap, Athena for queries), ScyllaDB (high-throughput write, time-series partitioning). (4) Schema: use Avro with schema registry (binary, compact) instead of JSON (50% smaller). (5) Buffer in memory: accept events in memory ring buffer (Disruptor pattern), flush to Kafka in batches — decouples ingest latency from Kafka write latency.

✓ Strong Answer

Immediate triage (first 5 min): check dashboards — is it CPU, memory, DB connections, or cache miss rate? Likely culprits at 10x: (1) Redis hot key — a single short URL getting millions of hits overwhelms one Redis slot. Fix: local in-process cache (Caffeine) in front of Redis, or Redis Cluster with key replication. (2) DB connection pool exhausted — HikariCP maxPoolSize too low. Fix: raise pool size, but also add a read replica and route read traffic there. (3) No CDN — redirect responses (301/302) are not cached by browser for short TTL. Fix: use 301 (permanent) for popular URLs so browsers cache and stop hitting origin. Architecture fix: cache the top 1% of URLs in-memory on every app node (80% of traffic is to 1% of URLs). Use Redis OBJECT ENCODING to store short string values efficiently. Pre-warm cache before IPL finals using analytics of trending URLs.

✓ Strong Answer

Root causes of duplicate messages: (1) Retry without deduplication — sender retries on timeout, server processed the first attempt but ACK was lost. (2) Consumer processes same Kafka message twice after a crash before offset commit. (3) Fan-out to multiple devices sends duplicate push notifications. Fix: (1) Idempotency key — client generates UUID per message send attempt. Server uses INSERT ... ON CONFLICT DO NOTHING with the idempotency key. (2) At-least-once to exactly-once in Kafka: use transactional producers + read_committed isolation in consumers. (3) Deduplication window: store message IDs in Redis with 24h TTL. On receive, check SET NX — if key exists, discard. (4) Client-side dedup: message ID in every payload, client ignores messages it already rendered.

✓ Strong Answer

Root causes: (1) Stale cache — rider location cached with too-long TTL. Fix: reduce TTL to 5s, or use cache invalidation on each location push. (2) WebSocket connection dropped — client fell back to polling with long interval. Fix: health-check WebSocket with ping/pong every 10s, auto-reconnect with exponential backoff. (3) Message queue lag — location events sitting in Kafka with high consumer lag. Fix: dedicate a high-priority partition for location events, monitor consumer lag. Architecture: Rider app → WebSocket/MQTT → Location Service → Redis (current position) + Kafka (history). Consumer app polls Redis at 3s intervals or gets pushed via WebSocket. Redis stores: rider_id → {lat, lng, timestamp} with 30s TTL (auto-expires stale riders).

✓ Strong Answer

The naive transaction (SELECT then UPDATE) fails under concurrent load — two requests read the seat as available simultaneously. Solutions by complexity: (1) Pessimistic locking: SELECT ... FOR UPDATE — database row lock prevents concurrent reads. Works but serializes all booking attempts for same seat. (2) Optimistic locking: Add version column. UPDATE seats SET status='booked', version=version+1 WHERE id=? AND version=? AND status='available'. If 0 rows updated → conflict → retry. (3) Redis distributed lock: SETNX seat:{id}:lock {userId} EX 30 — first request wins, others get lock error immediately. (4) Seat reservation queue: put seat into a reservation queue, single consumer processes one booking at a time per seat. Architecture: Reserve seat (30s hold) → Payment → Confirm. If payment fails, release hold. Redis SETNX for the 30s hold is the industry standard.

✓ Strong Answer

Root cause analysis: (1) CDN cache miss storm — new content hasn't propagated to edge nodes yet. Every user request hits origin. Fix: pre-warm CDN by programmatically fetching popular titles to all edge nodes 1hr before release. (2) Autoscaling lag — new EC2 instances take 3-5 min to be healthy. Traffic already overwhelmed existing fleet. Fix: pre-scale based on release schedule, use scheduled scaling policies. (3) Encoding pipeline backlog — new season just finished encoding, some resolutions not ready. Fix: prioritize most common bitrates (1080p, 720p) for encoding before release. (4) Origin bottleneck — even with CDN, some requests bypass cache. Fix: increase CDN TTL for new content, use signed URLs with long expiry. Adaptive bitrate streaming (HLS/DASH): when bandwidth is low, player should drop to 480p automatically.

✓ Strong Answer

Polling DB is fatal at scale. Real-time architecture: (1) Event streams: Driver location updates → Kafka topic driver-events. Rider requests → Kafka topic rider-requests. (2) Stream processing with Kafka Streams or Flink: sliding window of 5 minutes per geo-cell (H3 hexagonal grid). Compute supply/demand ratio per cell in real-time. (3) Pricing engine: subscribes to supply/demand metrics, applies surge multiplier formula. Publishes price updates to a Redis hash: surge:{hex_id} → multiplier. (4) App reads surge from Redis on every request (<1ms). H3 hexagonal indexing (Uber open-source): divides world into hexagons at different resolutions. Resolution 7 hexagon = ~1.2km², perfect for city-block level surge. Flink window: COUNT(driver_pings WHERE lat/lng IN hex AND timestamp > NOW()-5min) / COUNT(rider_requests WHERE ... ).

✓ Strong Answer

Root causes: (1) Cache not invalidated on write — after adding item, the cart service updates DB but the cache entry for that cart still has old data. (2) Read replica lag — write goes to primary, read comes from replica that hasn't synced yet (replication lag 100ms-2s). (3) Stale CDN cache — if cart API responses are cached at CDN level. Fix: (1) Write-through cache: on every cart mutation, update cache atomically with DB write. Use Redis pipeline or Lua script: SET cart:{userId} {newData} + DEL old_entry in one atomic operation. (2) Read-your-writes: route reads from the same user to primary DB immediately after a write (sticky session to primary for 5s). (3) Session affinity: ensure user's requests hit the same app server which has local cache. Amazon actually uses eventual consistency for cart intentionally — they prefer showing slightly stale data over blocking writes. The "merge on conflict" strategy: if two devices both modify cart, merge both versions (union of items).

✓ Strong Answer

Naive fanout (write to each follower's inbox) breaks for celebrities with 100M followers. Two models: (1) Fanout on write (push): when post created, write to each follower's feed. Works for average users (500 followers). (2) Fanout on read (pull): celebrity's feed is computed at read time — merge celebrity posts with regular posts. Hybrid: use push for users with <10K followers, pull for celebrities. Notification pipeline: Post Event → Kafka → Fan-out Service → Priority queues (Redis lists): HIGH (DMs, mentions), MEDIUM (likes on your posts), LOW (likes on posts you liked). Push Notification Workers pull from queues and call APNs/FCM. Rate limiting per user: max 5 notifications/hour of LOW priority to avoid spam. Backpressure: if APNs is slow, queue builds up — monitor queue depth, shed LOW priority notifications when queue > 1M.

✓ Strong Answer

Cross-service DB transactions (2PC) are an antipattern in microservices — creates tight coupling and coordinator single point of failure. Saga pattern: sequence of local transactions with compensating transactions for rollback. Choreography-based Saga: (1) Order Service creates order (PENDING) → publishes OrderCreated event. (2) Payment Service consumes event, charges card → publishes PaymentCompleted or PaymentFailed. (3) If PaymentCompleted: Order Service updates to CONFIRMED, Inventory Service reserves stock. (4) If PaymentFailed: Order Service updates to FAILED, sends cancellation email. Compensating transactions: if Inventory reservation fails after payment, Payment Service must issue refund (compensation). Idempotency is critical: payment service must handle duplicate OrderCreated events without double-charging (idempotency key = orderId).

✓ Strong Answer

End-to-end pipeline: (1) Upload: Client uploads directly to S3 (pre-signed URL) in chunks (multipart upload). For large files (2GB), chunked upload resumes after network drop. Server generates pre-signed URL, client uploads directly — no video bytes through API servers. (2) Trigger: S3 event → SQS → Transcoding Workers. (3) Transcoding: FFmpeg workers pull from SQS. Transcode to multiple bitrates in parallel: 360p, 480p, 720p, 1080p, 4K. Workers are spot EC2 instances (80% cheaper). Each resolution is a separate job — 4 workers run in parallel. (4) Manifest generation: create HLS .m3u8 playlist file linking all bitrates. Upload to S3. (5) CDN: CloudFront in front of S3. On first play, CloudFront pulls from S3 and caches at edge. (6) Storage: raw upload in S3 IA (infrequent access), processed in S3 standard. After 90 days, move to Glacier.

✓ Strong Answer

Root cause: consumer processed event, crashed before committing offset. On restart, it re-reads from last committed offset and reprocesses. Kafka guarantees at-least-once by default. Fixes: (1) Idempotent consumer: every event has a unique event_id. Before processing, check Redis: GET processed:{event_id}. If exists, skip. After processing, SET processed:{event_id} 1 EX 86400. (2) Atomic offset commit: process event + commit offset in same transaction using Kafka Transactions API. (3) enable.idempotence=true on producer: prevents producer-side duplicates (network retry causing double publish). (4) Manual offset commit (not auto-commit): only commit after successful processing + downstream write. auto.commit.interval.ms default is 5000ms — consumer can read 5s worth of events that get reprocessed on crash. Use commitSync() after each batch for exactly-once processing guarantee at the cost of lower throughput.

✓ Strong Answer

Kafka guarantees ordering only within a partition. Root cause: (1) Events for same order routed to different partitions (wrong partition key). (2) Multiple consumers in the group — events for same order processed by different consumer instances. Fix: (1) Partition by order_id: producer.send(new ProducerRecord("orders", orderId, event)) — all events for same order go to same partition, processed by same consumer. (2) Sequence numbers: include sequence_number in every event. Consumer maintains per-order state: if event.seq > expected_seq, buffer it; process buffered events in order. (3) Resequencing buffer: hold events for max 5 seconds, then process in sequence order. (4) Event sourcing: store all events with sequence number in DB, replay in order on demand. Key insight: if you need global ordering across partitions, you can only use 1 partition — which kills throughput. The correct design is partition-level ordering with meaningful partition keys.

✓ Strong Answer

Flash sale creates a notification storm — millions of users notified simultaneously. Scaling alone doesn't help if APNs/FCM has rate limits. Architecture for resilience: (1) Queue buffer: all notification requests go to Redis queue (not directly to service). Workers drain at a controlled rate (e.g., 50K/sec). Queue absorbs traffic spikes. (2) Backpressure: if queue depth > 1M, start shedding LOW priority notifications (promotional). MEDIUM priority (order updates) and HIGH priority (payment) always go through. (3) Rate limiting per user: max 1 notification per 30 seconds to same user — collapse duplicates. (4) Circuit breaker: if APNs error rate > 5%, stop calling for 30 seconds — prevents cascade failure. (5) Token bucket per notification type: promotional = 10K/sec token bucket; transactional = 100K/sec. Retry with exponential backoff for failed notifications.

✓ Strong Answer

JOINs require data from multiple rows/tables to be brought together — at 1B users, a JOIN between users (1B rows) and follows (500B rows) is not feasible in real-time. Instagram's approach: (1) Denormalization: store follower count directly on the user record (redundant data). Update the counter on every follow/unfollow. Trade space for join elimination. (2) Pre-computed feeds: user's feed is pre-computed and stored as a list of post_ids in Redis. No JOIN needed at read time. (3) Separate read models: write model (normalized, SQL) for data integrity; read model (denormalized, Redis/Cassandra) for high-speed reads. (4) Application-level joins: fetch user IDs from one service, fetch user profiles from another service in parallel. Each service queries its own DB with simple PK lookups (no JOINs). (5) Materialized views updated asynchronously via event stream.

✓ Strong Answer

Hot partition: DynamoDB distributes data across partitions by partition key hash. If all writes go to one partition key (e.g., date=2026-06-03 as the key), one partition gets all traffic regardless of provisioned throughput. Fixes: (1) Write sharding: append a random suffix to partition key. Instead of date=2026-06-03, use date=2026-06-03#1, date=2026-06-03#2, ..., date=2026-06-03#10. Reads must query all 10 shards and merge. (2) Composite key design: use (user_id, timestamp) instead of just (timestamp). Distributes writes by user. (3) High-cardinality partition key: use UUID or user_id (millions of distinct values) instead of status (5 distinct values — all PENDING writes hit same partition). (4) DynamoDB adaptive capacity: auto-rebalances hot partitions by giving them more of the provisioned throughput. But this is mitigation, not prevention. (5) For time-series: use composite key (device_id, week) — distributes by device AND limits partition size (1 week of data per partition).

✓ Strong Answer

Cache stampede (thundering herd): multiple cache entries set with the same TTL all expire simultaneously. Thousands of requests simultaneously find cache miss, all hit the DB at once, DB is overwhelmed, service goes down. Prevention strategies: (1) TTL jitter: instead of TTL=3600, use TTL = 3600 + random(0, 600). Distributes expiry over 10 minutes. (2) Probabilistic early expiration (PER): start refreshing cache before it expires. If TTL < 10% remaining, 1% of requests trigger a background refresh. (3) Request coalescing (mutex/lock): first request on cache miss acquires a Redis lock and fetches from DB. All subsequent requests wait for the lock release and then read from fresh cache. setnx:refresh:{key} 1 EX 5 — only one process fetches. (4) Layered TTL: L1 in-process cache (Caffeine, 30s TTL), L2 Redis (5 min TTL) — even if Redis expires, L1 absorbs the spike. (5) Never-expire with async refresh: cache entry never expires; a background job refreshes it every N minutes. Old data is served during refresh.

✓ Strong Answer

Fine-tuning doesn't prevent hallucination — it just changes the distribution of likely outputs. RAG (Retrieval-Augmented Generation) grounds responses in facts: (1) Ingestion pipeline: chunk documents into 512-token segments → embed with text-embedding model (OpenAI ada-002 or local BGE-M3) → store in vector DB (Pinecone, Weaviate, pgvector). (2) Query pipeline: user question → embed question → cosine similarity search in vector DB → retrieve top-5 relevant chunks → inject into LLM prompt as context → LLM answers ONLY from provided context. (3) Prompt engineering: "Answer ONLY using the provided context. If the answer is not in the context, say you don't know." (4) Citation: ask LLM to include source reference for each claim. (5) Confidence scoring: if similarity score of retrieved chunks is low (<0.7), don't answer — say "I don't have reliable information on this." Chunking strategy matters: semantic chunking (by paragraph) > fixed-size chunking.

✓ Strong Answer

Cost = (input_tokens + output_tokens) × price_per_token × request_count. Attack all three: (1) Token optimization: trim prompts — remove filler words, use abbreviations in system prompt, truncate context to relevant sections only. Use tiktoken to measure token count before every call. (2) Model routing: not every request needs GPT-4. Simple classification → GPT-3.5 (10x cheaper). Complex reasoning → GPT-4. Implement a router that classifies request complexity and routes to cheapest adequate model. (3) Semantic caching: cache LLM responses by embedding similarity of the question. If new question is >95% similar to a cached question, return cached answer — 0 LLM calls. Redis + vector similarity for cache lookup. (4) Response streaming: stream tokens to user so they see results immediately, but billing is same — this is UX only. (5) Batching: combine multiple short requests into one API call using the Batch API (50% cheaper, async). (6) Output length control: max_tokens parameter + clear prompt instructions ("Respond in 3 sentences or less").

✓ Strong Answer

2-second vector search is a configuration problem, not a hardware problem. Optimization layers: (1) ANN instead of exact search: exact k-NN scans all vectors (O(n)). Use Approximate Nearest Neighbor: HNSW (Hierarchical Navigable Small World) index — O(log n) search. Target: 10ms for 1M vectors. (2) Index tuning: HNSW parameters: ef_construction (build quality vs speed) and ef_search (search quality vs speed). Reduce ef_search from 200 → 50 for 4x speedup (slight recall drop from 99% to 95%). (3) Quantization: store vectors as int8 instead of float32 (4x smaller, 2x faster) using Product Quantization (PQ). Acceptable recall drop from 99% to 96%. (4) Batching: batch multiple queries into one search call. (5) Pre-filtering: filter by metadata BEFORE vector search to reduce candidate set. (6) Caching: cache results for common queries in Redis (same question → same top-K results). (7) Async prefetch: for user sessions, predict next query and pre-fetch results.

✓ Strong Answer

OTP failure cascade: (1) Single SMS provider fails → all OTP requests fail. (2) Users retry repeatedly → retry storm floods the provider → provider throttles you → more failures. Solution: (1) Multi-provider failover: primary (Twilio), secondary (MSG91), tertiary (AWS SNS). If primary fails (error rate > 5% in 30s window), circuit breaker opens, route to secondary. (2) Rate limiting: max 3 OTP requests per phone number per hour. Redis INCR with TTL. Prevents retry storm from users. (3) Retry with exponential backoff: first retry after 10s, second after 30s, third after 2min. Not immediate retry. (4) Queue buffer: OTP requests go to SQS, worker sends OTP. Queue absorbs spikes, worker sends at controlled rate. (5) Fallback to email/WhatsApp: if SMS fails, offer alternative channels. (6) Caching OTP: generate OTP once, store in Redis with 10min TTL. Resend uses same OTP (no new generation). (7) Monitoring: alert on delivery rate <95%, p99 latency > 5s.

✓ Strong Answer

Non-technical stakeholders care about three things: risk, cost, and benefit — not technical details. Framework: (1) Lead with business impact: "We need to migrate our database. Without this, we risk 2-3 hour outages during peak traffic, which costs us roughly ₹50L per incident." (2) Frame options and tradeoffs: "We have 3 options — do nothing (cheapest short-term, highest risk), partial migration (moderate cost, reduces risk 70%), full migration (₹10L investment, eliminates the risk)." (3) Recommendation + confidence: "We recommend the full migration. Our team has done this 3 times. We're 90% confident we can complete it with zero downtime." (4) Risk mitigation visible: "We'll run a full rehearsal in staging. We'll migrate on a Sunday morning at 2 AM when traffic is <1% of peak. We have a tested rollback plan." Never use jargon (sharding, replication lag, ACID). Replace with: "our database can't keep up with growth" instead of "we're hitting write throughput limits."

✓ Strong Answer

Blocking another team is a P1 that overrides sprint priorities. Immediate response: (1) Acknowledge within 1 hour: "I see you're blocked. I'm looking into this now. I'll have an update by 2 PM." This stops escalation and shows ownership. (2) Diagnose: is this a bug in my API, a missing feature, a documentation gap, or a misconfiguration on their side? (3) If it's my bug: hotfix within same day, coordinate deployment. If it's a feature gap: provide a workaround immediately (even if ugly) + schedule the proper fix. If it's their misconfiguration: pair program with them to fix it right now. (4) Written update to both teams' managers so they're not surprised. (5) Post-resolution: add the scenario to my API docs so next team doesn't hit the same issue. Communication style: specific ("your API call is missing header X-Client-Id"), not vague ("there might be an issue with authentication").

✓ Strong Answer

Code review is a collaborative act, not a judgment. Principles: (1) Comment on code, not the person: "This function does too many things" not "You wrote this function wrong." (2) Explain why: "I'd suggest extracting this into a helper because it's tested independently and reused in X service" — gives context, not just criticism. (3) Distinguish blocking vs non-blocking: "nit: rename to userCount for clarity [non-blocking]" vs "[blocking] This will cause a race condition under concurrent writes — see line X." (4) Ask questions first: "Is there a reason we're not using the existing UserValidator here?" — maybe they know something you don't. (5) Positive feedback matters: "Nice use of the builder pattern here — much cleaner than what we had before." (6) Offer to pair: "This is complex to explain in text — want to pair for 15 min?"

✓ Strong Answer

Documentation fails for one reason: it's written for the author, not the reader. Principles of docs that get read: (1) Start with "why" — what problem does this service solve? Who uses it? Not the implementation details. (2) Show before tell — code example first, explanation second. Engineers skim to the first code block. (3) Runbook format for operational docs: step-by-step, copy-paste commands, no paragraphs. (4) Keep it close to code — in-repo ADRs (Architecture Decision Records) and README files age better than Confluence pages. (5) "Getting started in 5 minutes" section at the top — most readers are onboarding, not looking for edge cases. (6) Link to runnable examples — a working Postman collection or curl command is worth 10 paragraphs. Structure: Overview → Quick Start → API Reference → Runbook → Architecture. Update the docs in the same PR as the code change — never as a separate ticket.

✓ Strong Answer

Amazon's Leadership Principle: "Have Backbone; Disagree and Commit." The framework: (1) Make your case once, clearly and with data. Write it down. "I believe approach A has 3x better performance at the same cost. Here's the benchmark." (2) Understand their constraints — managers often have context you don't (budget, timeline, org politics). Ask: "Help me understand the constraints driving this decision." (3) Propose a validation: "Can we do a 2-sprint spike to validate my concern before we commit?" This is a low-stakes way to resolve technical disagreements with data. (4) If overruled: commit fully. Half-hearted execution of a decision you disagree with is worse than the original decision. Document your concern in writing (email/doc) — not to cover yourself, but so it's traceable. (5) Know when to escalate: if the decision is ethically wrong or will cause user harm, escalate to skip-level. If it's just a technical preference, commit.

✓ Strong Answer

Technical disagreements between seniors are healthy — they usually reflect real tradeoffs. Resolution process: (1) Surface the criteria first: ask both engineers to write down the decision criteria independently. Consistency requirements? Read/write ratio? Team expertise? Budget? Often they agree on criteria but weight them differently. (2) Time-box exploration: each engineer has 3 days to build a proof-of-concept for their preferred solution. Compare on the agreed criteria with real numbers, not opinions. (3) Structured decision document: write an RFC (Request for Comments) with both options, tradeoffs, and a recommended choice. Share with wider team for 48h feedback. (4) Decision owner: if still tied, the tech lead makes the call — not by seniority of the advocate, but by who has accountability for the service's SLA. (5) Document the decision as an ADR so the reasoning is captured for future team members.

✓ Strong Answer

Blanket refusal without engagement damages the relationship. Better approach: (1) Understand the urgency: "Help me understand — is there a specific deadline or business consequence if we don't ship by Friday?" Maybe the PM doesn't realize a 4-hour code review delay is all that's left. (2) Separate process from outcome: "I want to get this shipped as much as you do. The risk I'm trying to mitigate is X." Be specific about what could go wrong — "this payment code has a race condition that would cause double charges if untested." (3) Offer alternatives: async review (reviewer looks at PR in 2 hours), feature flag (ship to 1% of users while review completes), or pair programming (review happens in real-time during coding). (4) If they insist on skipping: "I'm willing to ship, but I want to document this decision and the risk we're accepting." This creates accountability and often changes the calculus. (5) Escalate if it's a security/compliance code — those never skip review regardless.

✓ Strong Answer

Two parallel tracks: (1) Immediate: mitigate the security risk — is the vulnerability actively exploitable? If yes, coordinate an emergency rollback or hotfix NOW, before any conversation about process. Security risk trumps everything. (2) Conversation with colleague: private, not public — "I noticed PR #456 went directly to production. I wanted to flag that it has a CSRF vulnerability that could allow account takeover. Were you aware of this? I want to make sure we fix it together." Most violations are mistakes, not malice. (3) Document the incident in a blameless post-mortem: what happened, how it was caught, what the risk was, what the fix was, what process change prevents recurrence. (4) If it's a pattern (second time): involve the manager. Frame it as process improvement, not disciplinary action. (5) If it's malicious or repeated: escalate to manager with documented evidence.

✓ Strong Answer

"Second system syndrome" — rewrites almost always take 3-5x longer than estimated and often reproduce the same bugs. Decision framework: (1) Define what "broken" means specifically: what are the measurable problems? Bug rate? Deployment frequency? Onboarding time? If you can't measure the problem, you can't measure the solution. (2) Calculate the cost of each path: refactor = 6 months, team of 3 = 18 engineer-months. Rewrite = estimated 6 months (likely 18 months realistically) = 54 engineer-months + risk of feature parity gap. (3) Strangler Fig pattern: rewrite incrementally, one module at a time, while keeping the system running. Captures 80% of rewrite benefits with 30% of the risk. (4) Decision matrix: score both options on: risk, time to benefit, cost, maintainability in 2 years, team confidence. (5) Time-box: pick one approach for a 6-week spike. If refactoring makes measurable progress, continue. If not, revisit.

✓ Strong Answer

Start with curiosity, not judgment. Steps: (1) Private 1:1 — "I've noticed estimates often run longer than expected. I want to understand what's happening. Are there blockers I'm not aware of? Is the work more complex than we estimated upfront?" (2) Root cause matters: is it over-perfectionism? Underestimating complexity? Context-switching from other demands? External factors? Each has a different solution. (3) If perfectionism: "The 80% solution that ships on time is more valuable than the 100% solution that ships 3 weeks late. Let's define 'done' more explicitly before the sprint starts." (4) If under-estimation: pair on estimation sessions, break tasks into smaller chunks, add buffer explicitly. (5) If external factors: remove blockers, protect their focus time. (6) Set clear expectations going forward: "In the next sprint, if a task looks like it will miss the estimate by more than 1 day, flag it immediately so we can adjust." (7) If no improvement after 2 sprints: involve manager.

✓ Strong Answer

Passive consumption doesn't build real knowledge. My actual system: (1) Weekly: scan the DDIA (Designing Data-Intensive Applications) changelog mindset — for every new tech I encounter, I ask: what problem does this solve that existing tech doesn't? (2) Hands-on rule: I only count a technology as "learned" after I've built something with it. No tutorials without output. (3) Sources I trust: official changelogs > blog posts > YouTube. High-quality newsletters: ByteByteGo, The Pragmatic Engineer, TLDR Tech. (4) Concrete example: Kafka KRaft (removal of ZooKeeper). I read KIP-500, set up a local KRaft cluster, compared failover behavior to ZooKeeper mode, wrote an internal note for the team. Now I can speak to it in interviews and architecture discussions with specifics. (5) Conference talks: P99 CONF, QCon, Strange Loop — recordings are free and practitioners talk about real systems, not toy examples.

✓ Strong Answer

Structure: Situation → What I knew vs didn't know → Learning process → Resolution → What I retained. Example pattern: "We had a Cassandra performance degradation I'd never seen. Cassandra wasn't my area. I had 2 hours before the incident SLA breached. Process: (1) Read the error messages literally — they're usually specific. (2) Official docs first (Cassandra operations guide), not Stack Overflow — for production issues, SO answers are often outdated or wrong. (3) Found: compaction was backed up, causing read performance collapse due to SSTables multiplication. (4) Used nodetool commands to check compaction stats. (5) Triggered a compaction manually on the hot partition. Fixed in 45 min. (6) Aftermath: wrote a runbook for this scenario so the next person takes 5 minutes not 45." The key: I didn't pretend to know Cassandra — I said "I need 15 minutes to research this" — and came back with a specific hypothesis.

✓ Strong Answer

Evaluation criteria in order of importance: (1) Solves a real problem: does it solve a problem we actually have, or is it solving a problem we don't? YAGNI applies to libraries too. (2) Production maturity: how old is it? (>2 years preferred). Who else runs it in production at scale? (GitHub sponsors, companies using it). Check the issue tracker: are P0 bugs fixed promptly? (3) Maintenance health: commit frequency, response time to issues, clear roadmap. A library abandoned for 2 years is a liability. (4) Dependency footprint: what does it pull in? Deep transitive dependencies are a security and update burden. (5) Performance benchmark: does it perform adequately for our use case? Run a realistic benchmark, not the vendor's hello-world benchmark. (6) Team expertise: can the on-call engineer debug it at 2 AM? If not, the learning cost must be factored in. (7) License: Apache 2.0 / MIT (safe). AGPL, SSPL, BSL (check with legal). Red flag: library with no license.

✓ Strong Answer

"Document everything" is not actionable. Specific practices: (1) Bus factor audit: which critical knowledge lives in only one person's head? Identify the top 3 risks. Rotate ownership of these areas proactively. (2) Onboarding documentation: maintain a living onboarding guide. Every new hire updates it as they onboard — they catch gaps the originals can't see. (3) Runbooks in the repo: every incident that required tribal knowledge to solve gets a runbook entry. Next time it's a 5-minute fix, not a 45-minute re-investigation. (4) Tech talks: monthly 30-minute internal talks. Engineers present something they learned or built. Creates shared vocabulary and surfaces hidden expertise. (5) Pair programming rotations: deliberately rotate pairs so knowledge spreads. Junior learns from senior; senior's knowledge becomes less siloed. (6) ADRs: every major architectural decision is written down with the "why." When the original decision-maker leaves, the reasoning survives.

✓ Strong Answer

Structured 30-day plan: Week 1 (context): (1) Architecture walkthrough (2hr session) covering the system map, data flows, and key design decisions. (2) Set up local dev environment — the README must be runnable on day 1. (3) Shadow an on-call rotation — observe (don't respond). See how real incidents are handled. (4) Read the last 3 post-mortems — fastest way to understand failure modes. Week 2 (hands-on): (5) First PR — small, scoped bug fix in a well-understood area. Guided code review. (6) Pair program with 2 different team members. Week 3-4 (ownership): (7) Own a small feature end-to-end — design, implement, review, deploy. (8) Present a "newbie perspective" retro — what was confusing? What docs were wrong? Their fresh eyes catch gaps. Success metrics at day 30: can deploy independently, can identify the owner of any component, knows who to call for any type of incident.

✓ Strong Answer

Most retros fail because action items are never implemented. High-impact retro: (1) Rotate facilitator — the same person running every retro creates the same blind spots. (2) Anonymous input first (Miro/EasyRetro) — prevents the loudest voice from dominating. Collect input before the meeting, not during. (3) Cluster themes — group related items, vote on top 3 to discuss (dot voting). Time-box: 25 min of discussion on the top items. (4) Action items must have: owner + due date + definition of done. "Improve code review process" is not an action item. "By Friday, add a code review checklist to CONTRIBUTING.md (owner: Priya)" is. (5) Start next retro with reviewing last retro's action items — creates accountability. Did we do them? Did they work? (6) Retro the retro annually — is this format still working? Is attendance voluntary or mandatory?

✓ Strong Answer

The "20% rule" often becomes 0% in practice when sprints are tight. Sustainable approaches: (1) Tech debt as features: frame tech debt in terms of business impact. "Refactoring the payment module will reduce incident rate by 50%, saving 8 engineer-hours/month in on-call." This language resonates with PMs. (2) Boy Scout Rule: leave code cleaner than you found it. Every feature PR includes small cleanup in touched files — no separate ticket, no negotiation. (3) Tech debt budget: negotiate a fixed "infrastructure" allocation per quarter (not per sprint). E.g., 1 week per quarter per engineer is dedicated to tech debt. Protect it like a feature commitment. (4) Track the cost: maintain a "tech debt register" with estimated impact and cost-to-fix for each item. The PM can then make informed prioritization decisions — they often choose to fix high-cost debt when they see the numbers. (5) Never ship new tech debt: stricter definition of "done" prevents the accumulation problem.

✓ Strong Answer

Requiring 2 approvals on every PR is a bottleneck — it doubles review time without doubling quality. Instead: (1) Automate style: zero human review time on formatting, imports, naming conventions — linters and formatters handle this in CI. (2) Risk-tiered review: critical code (payments, auth, data migrations) → 2 required reviews. Normal code → 1 review, self-merging OK after 24h if no feedback. Config changes → owner can self-approve. (3) PR size limits: hard limit of 400 lines of logic changes. Large PRs get worse reviews because reviewers lose context. (4) Review SLA: define a team norm — all PRs get a first response within 4 working hours. Track this. (5) Review guidelines: a one-page checklist of what to look for (correctness, security, test coverage, performance edge cases) so reviewers know what they're responsible for. (6) Async review culture: use GitHub Conversations for questions, not blocking. Draft PRs for early feedback before "ready for review."

✓ Strong Answer

Structure: Situation → Why it was "not my problem" → Why I took it anyway → What I did → Outcome. Example: "Our checkout service latency was spiking every Tuesday at 11 PM. Root cause was a batch job in the data team's pipeline that ran weekly and hammered the shared Redis cluster. The data team said it was low priority for them. I had two choices: wait (and keep having Tuesday incidents) or fix it. I (1) added connection limits to the batch job's Redis client (a 2-line config change), (2) scheduled the batch for 2 AM instead of 11 PM, (3) set up an alert for Redis memory > 80% that paged both teams. I made the change in their repo (with their review), documented it, and added a note to their runbook. The data team was grateful — it fixed a problem they hadn't prioritized." Key: I didn't wait for permission — I proposed a fix, explained the business impact, and implemented it with minimal friction.

✓ Strong Answer

Reactive monitoring is not enough. Proactive approaches: (1) Dependency SLO tracking: if your service has a 99.9% availability SLA, each dependency must have a higher SLA (99.99%) to leave you budget. Map your error budget: monthly downtime budget = 43 min. If dependency takes 30 min → you have 13 min left for your own failures. (2) Circuit breakers for every external call: Resilience4j with configurable thresholds. When dependency fails, stop calling it and return cached/default response. (3) Fallback strategies: for non-critical dependencies (recommendations, analytics), degrade gracefully — serve without that data rather than failing the whole request. (4) Timeout + retry hygiene: every HTTP call has an explicit timeout (500ms for sync calls). Retries use exponential backoff + jitter + max 3 attempts. (5) Chaos testing: inject failures in staging to verify fallbacks work. (6) SLA contracts: get written SLOs from dependencies. If they can't meet your needs, design around them.

✓ Strong Answer

Day 1-30 (understand before acting): (1) Resist the urge to fix things immediately — understand first. (2) Shadow every incident in the next 30 days. Understand the failure patterns. (3) Read the last 12 months of post-mortems. Identify recurring themes. (4) Map the system: draw the architecture from scratch (don't trust the docs). Identify every external dependency. (5) Identify the top 3 high-impact, high-frequency incident types. Day 31-60 (quick wins): (6) For each top-3 incident type: add an alert that would have caught it earlier. Add a runbook entry for the fix. Fix if the fix is < 3 days of work. (7) Add basic RED metrics (Rate, Errors, Duration) to every endpoint if missing. (8) Set up a synthetic monitor — a canary that pings the service every minute and pages on failure. Day 61-90 (strategic improvements): (9) Address the root cause of the top incident type (usually 1 design flaw drives 80% of incidents). (10) Establish an on-call rotation with explicit severity levels and escalation paths. (11) Define SLOs for the service for the first time. Present findings and roadmap to stakeholders.

✓ Strong Answer

REST: best default choice. Cacheable (HTTP GET responses cached by CDN/browser), widely understood, great tooling. Use when: public API (external developers need simplicity), CRUD operations, team unfamiliar with alternatives, response caching matters. GraphQL: solves the over-fetching/under-fetching problem. Client specifies exactly what fields it needs — no more, no less. Use when: multiple clients (mobile, web, partner) need different data shapes from the same data, high bandwidth cost (mobile), complex relational data with variable fetch patterns. Watch out: N+1 queries without DataLoader, no HTTP caching for POST requests, harder to rate limit per field. gRPC: binary Protocol Buffers, bidirectional streaming, strongly-typed contracts with code generation. 5-10x faster than JSON/REST for the same payload. Use when: internal service-to-service communication, high-throughput (10K+ RPS), streaming (server push, client streaming), polyglot teams needing type safety across languages. Avoid for: public APIs (browser support requires gRPC-Web proxy), team unfamiliar with Protobuf.

✓ Strong Answer

Idempotency means: calling the operation N times has the same effect as calling it once. Why it matters: at scale, clients retry on timeout (the network dropped the response, not the request). Without idempotency, retries cause double charges, duplicate orders, duplicate emails. HTTP idempotency by spec: GET, PUT, DELETE are idempotent. POST is not. Making POST idempotent: (1) Idempotency key header: client generates UUID per operation (X-Idempotency-Key: uuid-v4). Server stores: key → {status, response} in Redis with 24h TTL. On duplicate request: return stored response, don't re-execute. (2) Implementation: first request → acquire distributed lock (SETNX) → process → store result → release lock. Subsequent requests → cache hit → return stored result. (3) Response must be identical: don't return "already processed" — return the original 200 OK with the original response. Client can't distinguish first call from retry. Database-level: INSERT INTO payments (id, ...) ... ON CONFLICT (idempotency_key) DO NOTHING RETURNING * — atomic upsert.

✓ Strong Answer

URL versioning (/v1, /v2) is the simplest but has problems: clients must update base URL, multiple versions maintained in parallel indefinitely, no incentive to migrate. Better strategies: (1) Additive-only changes (non-breaking): adding new fields to response, adding new optional request fields, adding new endpoints. Never rename or remove fields. (2) Field deprecation lifecycle: mark field as deprecated in docs, add X-Deprecated header in response, maintain for 12 months, send migration guide emails, remove in v2. (3) Header versioning: Accept: application/vnd.api+json;version=2 — cleaner than URL but harder for browser testing. (4) Content negotiation: server returns both old and new field names during transition period. (5) If URL versioning: maintain v1 as a thin adapter that translates to the new internal API. Don't fork the entire codebase. (6) Consumer-driven contract testing (Pact): generate tests from actual consumer API calls — automated test for backward compatibility before every release.

✓ Strong Answer

100M req/day = 1,160 RPS average. But traffic is spiky — peak is 5-10x average. Strategy: (1) Multi-tier limits: per-second burst limit (100 req/sec per user), per-hour sustained limit (1000 req/hour per user), per-day quota (10K req/day per user). (2) Algorithm: Token bucket (preferred over fixed window): bucket refills at 100 tokens/min, max 100 tokens. Burst of 100 is allowed, then throttled. Smooth traffic, not hard cutoff at window boundary. Leaky bucket: requests drain at constant rate — no burst, pure rate limiting. Fixed window: simplest but allows 2x burst at window boundary. Sliding window log: most accurate, highest memory. (3) Redis implementation: INCR + EXPIRE for fixed window. Lua script for atomic token bucket: check token count, decrement, return remaining. (4) Response headers: X-RateLimit-Limit: 1000, X-RateLimit-Remaining: 432, X-RateLimit-Reset: 1717435200. (5) HTTP 429 Too Many Requests + Retry-After header. (6) Different limits per tier: free tier (100/day), paid tier (10K/day), enterprise (custom).

✓ Strong Answer

Environment variables are better than hardcoded secrets but still problematic: visible in process listings, logged accidentally, no audit trail, no rotation. Solutions by maturity: (1) Basic: AWS Secrets Manager or Parameter Store — store secrets encrypted, fetch at startup. IAM role grants access (no long-lived credentials). Auto-rotation for database passwords. (2) Advanced: HashiCorp Vault — centralized secrets management, dynamic secrets (generates time-limited DB credentials on demand), audit log, fine-grained policies. Kubernetes Secrets: base64-encoded (not encrypted by default) — encrypt etcd at rest. Use External Secrets Operator to sync from Vault/AWS Secrets Manager to K8s Secrets. (3) Never: secrets in git (even private repos — git history is forever), secrets in Docker images (docker inspect reveals env vars), secrets in logs. Implementation: each microservice has an IAM role (AWS) or Service Account (K8s). The role grants read-only access to its specific secrets. No shared credentials between services.

✓ Strong Answer

SSRF (Server-Side Request Forgery): attacker tricks your server into making HTTP requests to internal resources. Attack: POST /fetch?url=http://169.254.169.254/latest/meta-data/ → your server fetches the AWS metadata endpoint → attacker gets EC2 IAM credentials → full AWS account compromise. Prevention layers: (1) URL allowlist: only allow specific domains (not denylist — too easy to bypass with redirects, IPv6, DNS rebinding). Regex allowlist: ^https://(api\.example\.com|cdn\.example\.com)/. (2) DNS resolution validation: after resolving URL to IP, validate IP is not private (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16). Resolve DNS yourself, check IP, then make the request to the IP directly (not re-resolving — prevents DNS rebinding). (3) Disable redirects: many HTTP clients follow redirects by default. Disable or validate redirect destination URL too. (4) Use a dedicated fetcher service: isolate URL fetching to a sandboxed service with no access to internal network. (5) Block metadata endpoint: on EC2, block 169.254.169.254 at the firewall and via IMDSv2 (requires auth token for metadata access).

✓ Strong Answer

VPC perimeter security is the "castle and moat" model — once inside the perimeter, services trust each other implicitly. Zero-trust: never trust, always verify — even internal service-to-service calls. Implementation: (1) mTLS (mutual TLS): every service has a certificate. Calls are authenticated both ways — caller proves identity, receiver proves identity. Service mesh (Istio, Linkerd) automates certificate rotation and mTLS without app code changes. (2) Service identity: each service has a SPIFFE/SPIRE identity (cryptographic identity standard). Not "IP X is service A" — IPs change. Certificate-based identity that moves with the service. (3) Authorization policies: define which service can call which endpoint. Istio AuthorizationPolicy: "allow payment-service to call order-service:/checkout but not order-service:/admin." (4) Short-lived credentials: JWT tokens with 15-minute expiry passed between services. No long-lived API keys. (5) Network policies: Kubernetes NetworkPolicy as an additional layer — even if mTLS fails, the network blocks the connection.

✓ Strong Answer

Restart causes downtime. Zero-downtime rotation: (1) Dual-active period: configure the system to accept BOTH old and new credentials simultaneously. Add the new credential to the allowed list BEFORE removing the old one. (2) New credential → deploy → validate traffic uses new cred → remove old cred. (3) For DB passwords (most complex): (a) Create new DB user with same permissions as old. (b) Update secrets manager with new password. (c) Deploy app instances with new credential (rolling deploy — no restart, new pods use new cred). (d) Verify zero errors in APM. (e) Delete old DB user. (4) AWS IAM keys: use IAM role instead of long-lived access keys — roles auto-rotate and can't be leaked in the same way. (5) JWT signing keys: support multiple valid keys (JWKS endpoint returns a key set). Rotate by adding new key, wait for all tokens signed with old key to expire (15 min if short-lived), remove old key. (6) TLS certificates: cert-manager (K8s) automates renewal 30 days before expiry — truly automated rotation.

✓ Strong Answer

Authority is optional; credibility is not. Influence-based approach: (1) Build credibility first: be right consistently on smaller decisions. Engineers follow people who have a track record of sound judgment, not people with titles. (2) Written proposals: a well-written design doc forces precision. Vague opinions lose; documented proposals with data win. Share the doc 48h before any discussion — people need time to read and form views. (3) Find the advocates: 1-1 conversations before the group meeting. Understand objections, address them, build a coalition. Group decisions are won before the meeting. (4) Address the strongest counterargument head-on: "The main objection to this approach is X. Here's why X doesn't apply in our context, or here's how we mitigate X." (5) Separate "I recommend this" from "I insist on this." On reversible decisions, express a preference and let others decide. Reserve strong positions for irreversible or high-stakes decisions.

✓ Strong Answer

"Improve your communication" is not actionable. Specific development plan: (1) Diagnose the specific gap: writing (PRs, docs), speaking in meetings, 1-1 conversations, or presenting to stakeholders? Each requires different development. (2) For meeting communication: role-play before important meetings. "You're about to present the architecture to the PM. Walk me through it — I'll be the PM." Debrief: "You lost them when you went into MVCC details. Lead with 'what problem this solves,' then offer to go deep if they ask." (3) For written communication: pair on the first design doc. Show a good example. Review their draft with inline edits. Explain why each change — pattern recognition builds over time. (4) Safe practice reps: volunteer them for low-stakes presentations (team demos, not executive presentations). Build confidence first. (5) Positive reinforcement: notice when they communicate well — "your PR description today was excellent, very clear context." Specific positive feedback is more effective than generic praise.

✓ Strong Answer

A feature list is not a roadmap — it's a backlog. A roadmap communicates strategy. Process: (1) Month 1 — Diagnose: assess current state (reliability, developer productivity, operational cost, security posture). Quantify problems: deploy frequency, incident rate, p99 latency, developer onboarding time. (2) Define the 12-month outcomes (not features): "Reduce incident rate by 50%, increase deploy frequency from monthly to weekly, cut infra cost by 20%." (3) Theme the work: Q1: Foundation (reliability, observability). Q2: Developer Experience (CI/CD, local dev). Q3: Performance. Q4: New Capabilities. (4) Work backwards from outcomes to initiatives to milestones — each initiative maps to a measurable outcome. (5) Stakeholder alignment: share with PM, EM, and CTO for input. The roadmap must reflect business priorities, not just engineering preferences. (6) Buffer: 30% of capacity is unallocated — for incidents, unplanned work, and learning. Roadmaps without buffer fail reliably. (7) Monthly review: adjust for new information. A 12-month roadmap in a 3-month-cadence world is updated every quarter.

✓ Strong Answer

Trying to do both results in both being done poorly. Steps: (1) Make the conflict explicit — confirm it is a real conflict, not a miscommunication. "My manager asked me to prioritize X. My tech lead asked me to prioritize Y. Are these conflicting or can I sequence them?" Often they're not actually in conflict once priorities are stated clearly. (2) If genuinely conflicting: go to the source of each request and say: "I have two priority requests. I can complete one this week. Which should it be, and can you align with [other person] on sequencing?" This surfaces the conflict to the people who can resolve it — not you. (3) If they can't align: request a 3-way conversation. "Can we take 15 min together to align? I don't want to make this decision unilaterally." (4) If still not resolved: the manager's priority takes precedence for resource allocation. The tech lead owns technical direction; the manager owns delivery priorities. (5) Document the resolution: "I will complete Y first (as agreed in our conversation on [date]) and follow with X."

✓ Strong Answer

MVCC keeps multiple versions of a row simultaneously. How it works in PostgreSQL: (1) Every row has xmin (transaction ID that created it) and xmax (transaction ID that deleted/updated it, or 0 if still current). (2) When you UPDATE a row: the old row is marked with xmax = current_txn_id (not deleted). A new row is inserted with xmin = current_txn_id. Both versions exist simultaneously. (3) Readers see the version that was "current" at their transaction start time — based on their snapshot. Reader sees xmin ≤ snapshot_xid AND (xmax = 0 OR xmax > snapshot_xid). (4) No locks needed for reads — readers look at historical versions, never blocked by writers. (5) VACUUM: old versions accumulate. VACUUM removes row versions no longer needed by any active transaction. Without VACUUM, table bloat occurs (transaction ID wraparound). (6) REPEATABLE READ: you see a consistent snapshot of the DB as it was when your transaction started — even if other transactions commit during your read. This is snapshot isolation.

✓ Strong Answer

Adding an index blindly may not help. Optimization process: (1) EXPLAIN (ANALYZE, BUFFERS): read the execution plan. Is it a Seq Scan because: (a) no index exists? (b) index exists but selectivity is low (e.g., WHERE status='active' on 90% active rows — full scan is faster)? (c) table statistics are stale (run ANALYZE)? (2) If no useful index: add a B-Tree index on the filter column(s). Composite index: WHERE user_id=? AND created_at > ? → index on (user_id, created_at). Column order matters — highest cardinality first for range queries: (user_id, created_at) not (created_at, user_id). (3) If query has ORDER BY + LIMIT: covering index (includes all SELECT columns) avoids heap fetch. (4) Partial index: if WHERE status='pending' is common and only 1% rows are pending → CREATE INDEX ... WHERE status='pending'. Tiny index, very fast. (5) Partitioning: for time-series data, partition by month. Query on last 30 days touches only 1 partition (3M rows) not the full 500M. Partition pruning makes it transparent. (6) Materialized views: if the full-scan is for aggregation (GROUP BY), a materialized view pre-computes it. Refresh incrementally.

✓ Strong Answer

N+1: fetch 1 list (N items), then execute 1 query per item = N+1 total queries. Example: fetch 100 orders (1 query), then fetch customer for each order (100 queries) = 101 queries instead of 2. Root cause: ORM lazy loading. JPA/Hibernate: @OneToMany(fetch=LAZY) — accessing the collection triggers a new query per entity. Diagnosis: (1) Enable SQL logging: spring.jpa.show-sql=true or p6spy proxy — count queries per request in dev. (2) Production: slow query log + New Relic/Datadog APM shows queries-per-request metric. N+1 appears as hundreds of fast queries summing to high latency. Fix: (1) JOIN FETCH: SELECT o FROM Order o JOIN FETCH o.customer WHERE o.date > :date — single query with join. (2) @EntityGraph: @EntityGraph(attributePaths="customer") on the repository method — declarative eager loading. (3) Batch fetching: @BatchSize(size=50) on the collection — fetches 50 associations per query instead of 1. Still N/50+1 queries but 50x better. (4) DTO projection: SELECT new OrderDTO(o.id, c.name) FROM Order o JOIN o.customer c — bypasses entity graph entirely, returns only needed fields.

✓ Strong Answer

Running migrations on startup is dangerous: (1) Multiple instances start simultaneously, all try to run migration — needs distributed lock (Flyway uses advisory lock). (2) Migration runs while old version of app is still serving traffic — new schema must be compatible with old code. Zero-downtime migration rules: (a) Adding a column: safe if nullable or has a default. (b) Renaming a column: UNSAFE. Instead: add new column, dual-write to both, migrate data, switch reads to new column, drop old column (4 deployments). (c) Adding an index: use CREATE INDEX CONCURRENTLY — non-blocking. Never CREATE INDEX (locks table). (d) Adding NOT NULL: first add as nullable, backfill data, then add NOT NULL constraint. (e) Deleting a column: first remove from code (deploy), then drop column (next deploy). (f) Changing column type: most dangerous. Use a view or dual-column approach. Tools: Flyway (Spring standard), Liquibase (XML/YAML format), Atlas (schema-as-code, drift detection).

✓ Strong Answer

"Almost always Redis" is correct but knowing WHY matters. Memcached advantages: simpler, pure LRU eviction, scales horizontally via client-side hashing (each node is independent — no coordination). Better for simple key-value where you just need raw throughput. Redis advantages: (1) Rich data structures: String, List (LPUSH/RPOP = queue), Set (unique membership), Sorted Set (leaderboard with ZADD/ZRANGEBYSCORE), Hash (object fields), HyperLogLog (count distinct), Stream (append-only log), Bloom Filter (probabilistic membership). (2) Atomic operations: INCR, SETNX, GETSET — enables distributed locking, rate limiting, counters without application-level locks. (3) Pub/Sub + Streams: real-time messaging. (4) Persistence: RDB snapshots + AOF log — data survives restarts. (5) Lua scripting: multi-command atomic operations. (6) Geo commands: GEOADD, GEODIST, GEORADIUS — for location-based features without a separate geo database. Choose Memcached: pure cache, high write volume (>1M writes/sec), multi-threaded architecture. Choose Redis: anything beyond simple string caching, need persistence, need pub/sub, leaderboards, rate limiting, queues.

✓ Strong Answer

Cassandra has no joins. You model for the query, not the entity. Query: "Give me the 20 most recent posts from accounts I follow, sorted by time." Data model: CREATE TABLE user_feed (user_id UUID, post_time TIMESTAMP, post_id UUID, author_id UUID, content TEXT, PRIMARY KEY (user_id, post_time, post_id)) WITH CLUSTERING ORDER BY (post_time DESC); Write path: when user A posts → for each of A's followers → insert one row into user_feed. This is fanout on write. Read path: SELECT * FROM user_feed WHERE user_id=? LIMIT 20 — single partition read, O(1). Trade-offs: (1) Write amplification: celebrity with 1M followers = 1M Cassandra writes per post. (2) Post update/delete: must update 1M fan-out rows. Solution: hybrid — fan out to active followers only, use pull for inactive followers' feeds. Partition design: user_id as partition key → all of user's feed is on one node → hot partition for celebrities. Fix: time-bucket partitioning: (user_id, month) as partition key → fan out across time buckets.

✓ Strong Answer

DB sort for leaderboard at 10M users: O(N log N) per read, catastrophic at scale. Redis Sorted Set is purpose-built: (1) Data model: ZADD leaderboard:{game_id} {score} {user_id}. (2) Get top 100: ZREVRANGEBYSCORE leaderboard:{game_id} +inf -inf WITHSCORES LIMIT 0 100 — O(log N + 100). (3) Get user rank: ZREVRANK leaderboard:{game_id} {user_id} — O(log N). (4) Get user score: ZSCORE leaderboard:{game_id} {user_id} — O(1). (5) Update score: ZADD leaderboard:{game_id} {newScore} {user_id} (upsert, O(log N)). Memory estimate: 10M users × ~50 bytes/entry = 500MB — fits in one Redis node. (6) "Near me" ranking: ZREVRANK gives absolute rank. For "users near my rank": ZREVRANGE leaderboard:game OFFSET rank-10 LIMIT 20 — O(log N + 20). (7) Multiple leaderboards: weekly, monthly, all-time are separate sorted sets. Weekly expires with TTL at Sunday midnight.

✓ Strong Answer

The JMM (Java Memory Model) defines when one thread's writes are guaranteed to be visible to another thread. Without the JMM, the compiler and CPU can reorder instructions for performance — breaking multithreaded code in non-obvious ways. Happens-before (HB): if operation A happens-before operation B, then B is guaranteed to see A's writes. HB rules: (1) Monitor lock: unlocking a monitor HB acquiring the same monitor. (2) Volatile write: a volatile write HB all subsequent volatile reads of the same field. (3) Thread start: Thread.start() HB all actions in the started thread. (4) Thread join: all actions in a thread HB Thread.join() returning. volatile: guarantees visibility (write is immediately flushed to main memory, read always reads from main memory) and prevents reordering around the volatile access. Does NOT guarantee atomicity — volatile long/double on 32-bit JVMs is not atomic. synchronized: provides both visibility AND atomicity. The synchronized block is an "atomic action" — no other thread sees partial state. Also establishes HB. When to use which: volatile for a single flag (boolean, single-writer). synchronized or AtomicXxx for compound actions (check-then-act, increment).

✓ Strong Answer

Platform threads (OS threads): each thread = 1 OS thread = ~1MB stack. Limit: 10K-20K threads per JVM before memory exhaustion. Blocking I/O blocks the OS thread — thread sits idle, burning memory. Virtual threads: each virtual thread is a JVM-managed task that mounts onto a carrier thread (pool of OS threads). When a virtual thread blocks on I/O, it UNMOUNTS from the carrier thread — the carrier thread is free to run other virtual threads. Blocking no longer wastes OS threads. Implications: (1) Thread-per-request model is viable again: each HTTP request gets its own virtual thread. No more reactive programming needed for I/O concurrency. (2) Throughput: 10K-100K concurrent requests handled with a handful of OS threads. (3) Code style: blocking code (Thread.sleep, JDBC, HTTP) is fine — JVM makes it non-blocking underneath. (4) Migration: Spring Boot 3.2+ enables virtual threads with one line: spring.threads.virtual.enabled=true. (5) Caveats: CPU-bound tasks don't benefit (no I/O to unmount on). Synchronized blocks pin the virtual thread to the carrier (Java 21 limitation, fixed in Java 24). Use ReentrantLock instead of synchronized in performance-critical virtual thread code.

✓ Strong Answer

Restart is temporary — the deadlock will recur. Diagnosis: (1) Get a thread dump: kill -3 <pid> or jstack <pid> or curl http://localhost:8080/actuator/threaddump. (2) Look for "BLOCKED" threads that form a cycle: Thread A waits for lock held by Thread B; Thread B waits for lock held by Thread A. jstack output shows exactly which lock each thread is waiting for and which thread holds it. (3) In a JPA application: common deadlock = two transactions each holding a row lock and waiting for the other's row lock. Occurs when threads process the same rows in different orders. Fix patterns: (1) Consistent lock ordering: always acquire locks in the same order (e.g., always lock lower user_id before higher). (2) Timeout: @Transactional(timeout=5) — transaction rolls back after 5 seconds, deadlock resolves. (3) Optimistic locking: @Version field in JPA entity — instead of row locks, use version-based conflict detection. No lock held → no deadlock. (4) Reduce transaction scope: don't hold locks across network calls (e.g., calling an external API inside a transaction). (5) Use SELECT ... FOR UPDATE SKIP LOCKED for queue processing — skips locked rows instead of waiting.

✓ Strong Answer

Blue-green is simple for stateless services. Stateful (DB) complications: (1) Schema compatibility: during the cutover, both blue (old) and green (new) may serve traffic simultaneously (in case of partial failure). Both must be able to read/write the DB. New schema must be backward-compatible with old code AND new code. Expand/contract pattern: in deploy N, add new column (nullable). In deploy N+1, migrate data, start writing to new column. In deploy N+2, add NOT NULL constraint. Each deploy is independently deployable. (2) Traffic switch: use a load balancer or feature flag to route traffic. Route 1% → 10% → 50% → 100% to green. Monitor error rates at each step. (3) Rollback: keep blue running until green is stable (15 min). If green fails, switch 100% back to blue in <30 seconds. (4) Database migration: run migration BEFORE deploying green. The new migration must be backward-compatible with blue (old code still running). (5) Connection drain: when switching from blue to green, give blue 30 seconds to finish in-flight requests (connection drain) before stopping traffic.

✓ Strong Answer

The three pillars: (1) Metrics: numerical measurements over time. Rate (req/sec), Errors (error %), Duration (p99 latency). Prometheus scrapes metrics endpoints (/actuator/prometheus). Grafana visualizes. Metrics are cheap to store (aggregated), great for dashboards and alerts, but don't show WHY. (2) Logs: structured events with context. Use JSON logging (not plain text): {"level":"ERROR","traceId":"abc","userId":"123","msg":"payment failed","durationMs":450}. Log at WARN/ERROR for production. Centralize with ELK (Elasticsearch + Logstash + Kibana) or Loki + Grafana. Logs show WHAT happened, but correlation across services is hard. (3) Distributed Traces: a trace shows the full journey of a request across services. Spans: each service adds a span (start time, duration, metadata). Trace ID propagated via HTTP header (traceparent). OpenTelemetry is the standard SDK — auto-instruments Spring Boot, JDBC, HTTP clients. Jaeger or Grafana Tempo stores traces. Traces show WHERE latency is. Together: alert on metric (p99 > 500ms) → look at logs for that time window → follow trace ID → find the slow span.

✓ Strong Answer

Hardcoded if-else is not a feature flag — it requires a deployment to change. Real feature flags: (1) Config-driven: flag value stored in a config service (LaunchDarkly, AWS AppConfig, Unleash). No deployment needed to toggle. (2) Types of flags: (a) Release flags: hide incomplete features. Remove when feature is stable. (b) Experiment flags: A/B test — 50% users see variant A, 50% see B. (c) Ops flags: kill switch for a feature during incidents. (d) Permission flags: feature available only to beta users or specific tenants. (3) Targeting: flags can be evaluated per user, per tenant, per percentage, per environment. (4) Gradual rollout: release to 1% → 5% → 20% → 100%. Monitor metrics at each stage. Risks: (1) Flag debt: flags accumulate and are never removed — code becomes a maze of if-else. (2) Flag interaction: two flags interact unexpectedly when both enabled. (3) Stale flags: a flag meant to be temporary is still in code 2 years later. (4) Performance: flag evaluation is a remote call — cache flag values with short TTL (30s) to avoid latency. Discipline: every flag has an owner, a creation date, and an expiry date. Delete flags within 2 sprints of full rollout.

✓ Strong Answer

EAGER: when you load the parent entity, Hibernate immediately fetches all related entities. @OneToMany(fetch=FetchType.EAGER) — fetching 100 Orders also fetches all OrderItems for each. Creates N+1 or Cartesian product JOIN. LAZY: related entities are loaded only when the collection is first accessed. Hibernate creates a proxy object. The proxy loads data when you call .size() or iterate. LazyInitializationException (LIE): occurs when you access a lazy collection AFTER the Hibernate session is closed. Session is closed when the transaction commits. Common scenario: (1) @Transactional method loads Order with lazy OrderItems. (2) Method returns, transaction commits, session closes. (3) In the controller/view, code accesses order.getOrderItems(). (4) LIE: "could not initialize proxy — no Session." Fixes: (1) Open Session in View (OSIV): keeps session open through the view layer. Anti-pattern — causes N+1 queries silently and ties DB session to HTTP request duration. (2) Initialize in transaction: call Hibernate.initialize(order.getOrderItems()) within the @Transactional method. (3) JOIN FETCH: SELECT o FROM Order o JOIN FETCH o.orderItems WHERE o.id=:id. (4) DTO projection: return a DTO from the query, not the entity — no lazy proxies.

✓ Strong Answer

Cache hierarchy: L1 = first-level cache (per Session/EntityManager — entities loaded in a transaction are cached for that transaction's duration). L2 = second-level cache (per SessionFactory — shared across sessions and transactions). L2 cache stores entity state by ID. Query cache: stores query result sets (query string + params → list of IDs). Not the entities themselves — entities come from L2 cache. Configuration: (1) Enable: spring.jpa.properties.hibernate.cache.use_second_level_cache=true + spring.jpa.properties.hibernate.cache.use_query_cache=true. (2) Provider: EhCache (single-node), Infinispan or Hazelcast (distributed). (3) Annotate entities: @Cache(usage=CacheConcurrencyStrategy.READ_WRITE). Cache concurrency strategies: NONE (no caching), READ_ONLY (immutable entities — fastest), NONSTRICT_READ_WRITE (high performance, brief stale window acceptable), READ_WRITE (strict consistency via soft locks — locks on write), TRANSACTIONAL (full JTA-level consistency). Stale data risk: in a multi-node cluster, node A updates an entity and invalidates its local L2 cache. Node B still has the old version. Solution: distributed cache (Infinispan) — updates invalidate entries across all cluster nodes via JGroups multicast.

✓ Strong Answer

Connection pool basics: each thread that needs a DB query borrows a connection from the pool. If all connections are in use, threads queue and wait. Pool exhaustion = request timeouts. Tuning: (1) maximumPoolSize formula (HikariCP recommendation): core_count × 2 + effective_spindle_count. For a 4-core server with SSD: 4 × 2 + 1 = 9. For most cloud databases, 10-20 is the right range. Counterintuitively: more connections is NOT always better — DB server has its own limits (PostgreSQL default max_connections=100). 10 services × 20 connections = 200 connections → DB overhead from context switching degrades performance. (2) minimumIdle: set equal to maximumPoolSize (HikariCP recommendation) — avoid connection churn from scaling up/down. (3) connectionTimeout: how long to wait for a connection from pool before throwing exception. Default 30s. Set to 2-3s for user-facing APIs. (4) maxLifetime: connections are retired after this time (default 30 min) to prevent issues with DB-side connection limits. Monitoring metrics (Actuator/Micrometer): hikaricp.connections.active, hikaricp.connections.idle, hikaricp.connections.pending. Pool exhaustion: pending > 0 + active = maximumPoolSize → threads are waiting for connections. Fix: reduce query duration (N+1 queries!), or increase pool size (within DB limits).

✓ Strong Answer

ExecutorService: submit tasks to a thread pool, get back a Future. Blocking: future.get() blocks the calling thread until the result is ready. Good for: parallel CPU-bound work, fire-and-forget tasks, simple parallelism. CompletableFuture (Java 8+): non-blocking composition. thenApply(), thenCompose(), thenCombine() chain async operations without blocking. Callback-style. Good for: async I/O chains, combining multiple async results (CompletableFuture.allOf), timeout handling (completeOnTimeout). Limitation: no backpressure — can create thousands of pending futures if production is faster than consumption. Reactive Streams (Project Reactor / Mono/Flux): complete async pipeline with backpressure. Mono<T>: 0 or 1 result. Flux<T>: 0 to N results, streamed. Good for: streaming responses, high-throughput I/O pipelines where backpressure is needed, WebFlux. Learning curve high — debugging stack traces are complex. Java 21 virtual threads: for new code, virtual threads often replace CompletableFuture and reactive for I/O-bound services — simpler blocking code at reactive throughput. Summary: ExecutorService for CPU-bound tasks, CompletableFuture for moderate async chains, Reactive for streaming + backpressure, Virtual Threads (Java 21) for simple async I/O.

✓ Strong Answer

GC comparison: G1GC (Java 9+ default): concurrent, generational, region-based. Target: ≤200ms pause for most workloads. Actually pauses the app (STW — Stop-The-World) during certain phases (young GC, mixed GC, full GC). Throughput: very good. Memory overhead: ~10%. Best for: general purpose, 4GB-16GB heap, latency target ≤200ms. ZGC (Java 15+ production): concurrent, non-generational (Java 21 added generational ZGC). STW pauses: < 1ms regardless of heap size. Scales to terabyte heaps. Throughput: slightly lower than G1 (concurrent work costs CPU). Best for: heap >16GB, latency target <10ms, large heaps. ParallelGC (Java 8 default): throughput-optimized, longer STW pauses. Best for: batch processing, no latency requirements. ShenandoahGC: similar goals to ZGC, different algorithm. Red Hat-backed. Choice for latency-sensitive services: (1) If p99 latency SLO ≤ 50ms → ZGC. (2) If p99 latency SLO ≤ 200ms → G1GC. (3) If heap > 32GB → ZGC always. (4) If batch processing → ParallelGC for throughput. Tuning G1: -XX:MaxGCPauseMillis=100 (target pause goal, not guarantee). Monitor: GC log with -Xlog:gc.

✓ Strong Answer

Checked exceptions (extends Exception): compiler forces you to handle or declare (throws). Examples: IOException, SQLException, ClassNotFoundException. Intent: these are recoverable failures the caller should handle explicitly. Unchecked exceptions (extends RuntimeException): no compile-time requirement. Examples: NullPointerException, IllegalArgumentException, DataAccessException. Intent: programming errors or system failures typically not recoverable by the caller. Spring Boot microservice strategy: (1) Use unchecked exceptions exclusively. Spring's entire exception hierarchy (DataAccessException, etc.) is unchecked. Checked exceptions force callers to catch/rethrow boilerplate and pollute method signatures. (2) Custom domain exceptions extending RuntimeException: OrderNotFoundException, PaymentFailedException, InsufficientInventoryException. (3) Global exception handler: @ControllerAdvice + @ExceptionHandler — maps exceptions to HTTP responses. One place handles all exceptions for all controllers. (4) Never swallow exceptions: catch(Exception e) {} — makes debugging impossible. (5) Log with context: log.error("Failed to process order {}", orderId, e) — include the exception object for the full stack trace. (6) Exception translation: never let JPA/JDBC exceptions leak to the API layer — translate to domain exceptions in the service layer.

✓ Strong Answer

REST (Representational State Transfer) is an architectural style, not a protocol. 6 core constraints: (1) Client-Server separation — UI decoupled from storage. (2) Stateless — each request contains all info needed; server stores no session state between requests. (3) Cacheable — responses must declare themselves cacheable or not. (4) Uniform Interface — resource identification via URI, manipulation through representations, self-descriptive messages, HATEOAS. (5) Layered System — client can't tell if it's talking to end server or intermediary. (6) Code on Demand (optional) — server can send executable code. In practice: resources are nouns (not verbs), HTTP methods express intent (GET=read, POST=create, PUT=replace, PATCH=update, DELETE=remove), status codes convey outcome (200/201/204/400/401/403/404/409/500).

✓ Strong Answer

Process: an independent executing program with its own memory space (heap, stack, code, data segments), file descriptors, and OS resources. Isolated — one process crash doesn't affect others. IPC needed for communication. Thread: a unit of execution within a process, sharing the process memory space (heap, code, data) but with its own stack and registers. Cheaper to create (~10x vs process), faster context switch, but shared memory makes synchronisation necessary. In Java: each JVM runs in one process. Threads share the JVM heap (hence race conditions). JVM threads map 1:1 to OS threads (Java 21 virtual threads are multiplexed). Key difference: isolation vs efficiency. Containers (Docker) are like lightweight processes — each has its own filesystem/network namespace, but shares the OS kernel.

✓ Strong Answer

An index is a separate data structure (usually a B-Tree) that stores a sorted copy of one or more columns plus a pointer to the actual row. Without index: full table scan = O(n). With B-Tree index: O(log n). Types: (1) B-Tree (default) — balanced tree, supports =, <, >, BETWEEN, LIKE prefix. (2) Hash — exact-match only, O(1) but no range queries. (3) Composite/Compound — multiple columns; must follow leftmost-prefix rule. (4) Partial — indexes only a subset (WHERE is_active = true). (5) Covering index — includes all columns needed by query; no table lookup needed. Cost: every index slows down INSERT/UPDATE/DELETE (must maintain the index), uses storage. Write-heavy tables: minimize indexes. Read-heavy: index query predicates and sort columns.

✓ Strong Answer

SQL (Relational): structured data, fixed schema, ACID transactions, powerful JOINs, vertical scaling first. Best for: financial systems, ERP, any domain with complex relationships and integrity constraints. NoSQL (Not Only SQL): flexible/no schema, horizontal scaling, various data models. Types: (1) Document (MongoDB) — JSON documents, flexible schema. Best for: user profiles, product catalogs, CMS. (2) Key-Value (Redis, DynamoDB) — ultra-fast lookups by key. Best for: caching, sessions, leaderboards. (3) Wide-Column (Cassandra) — row key + columns, massive write throughput. Best for: IoT time-series, activity feeds. (4) Graph (Neo4j) — relationships as first-class citizens. Best for: social networks, fraud detection. Decision: start with SQL. Move to NoSQL when you have a specific problem (scale, schema flexibility, specific data model) that SQL can't solve efficiently.

✓ Strong Answer

A load balancer sits in front of a server pool, accepting client connections and forwarding to backends. Types: L4 (TCP/IP level — fast, no application awareness) and L7 (HTTP level — can route by URL, header, cookie; enables A/B testing, canary deployments). Common algorithms: (1) Round Robin — sequential distribution; simple but ignores server capacity differences. (2) Least Connections — sends to server with fewest active connections; better for variable request duration. (3) IP Hash — same client always hits same server; enables sticky sessions. (4) Weighted Round Robin — servers with more capacity get proportionally more requests. (5) Random — simple, effective with many backends. Health checks: LB probes backends (HTTP GET /health); removes unhealthy nodes automatically. Session persistence ("sticky sessions"): route same user to same server — needed for stateful apps but breaks horizontal scaling.

✓ Strong Answer

HTTP sends data as plain text — anyone intercepting network traffic can read credentials, tokens, and personal data. HTTPS adds TLS (Transport Layer Security) on top of HTTP. TLS Handshake: (1) Client sends ClientHello (TLS version, cipher suites, random nonce). (2) Server sends certificate (public key + identity signed by CA). (3) Client verifies certificate against trusted CAs. (4) Key exchange: client and server use asymmetric crypto (RSA or ECDHE) to establish a shared symmetric key. (5) All subsequent communication encrypted with symmetric key (AES-256). Certificates: issued by Certificate Authorities (Let's Encrypt is free). HSTS (HTTP Strict Transport Security): browser-side policy preventing downgrade attacks. TLS 1.3 (current standard) removes weak cipher suites, reduces handshake from 2 round trips to 1.

✓ Strong Answer

Deadlock occurs when: Thread A holds Lock 1, wants Lock 2. Thread B holds Lock 2, wants Lock 1. Both wait forever — Coffman conditions: Mutual exclusion, Hold and wait, No preemption, Circular wait. Java example: synchronized(lock1){ synchronized(lock2){ } } in Thread A and synchronized(lock2){ synchronized(lock1){ } } in Thread B. Prevention strategies: (1) Lock ordering — always acquire locks in the same global order (Thread A and B both take lock1 then lock2). (2) tryLock with timeout — ReentrantLock.tryLock(100ms) — fail and retry rather than wait forever. (3) Lock-free algorithms — atomic compare-and-swap (CAS) operations (AtomicInteger, ConcurrentHashMap). (4) Single lock/synchronized entry point — reduce lock granularity. DB deadlocks: PostgreSQL detects and kills one transaction (ERROR: deadlock detected). Fix: consistent row access order in all transactions.

✓ Strong Answer

Caching stores computed/fetched results to avoid repeating expensive operations. Strategies: (1) Cache-Aside (Lazy Loading) — app checks cache; on miss, reads DB and populates cache. Most common. Data only in cache when needed. Risk: cache miss storm on cold start. (2) Write-Through — writes go to cache AND DB simultaneously. Always consistent. Adds write latency. (3) Write-Behind (Write-Back) — writes go to cache, async flush to DB. Fastest writes, risk of data loss on cache crash. (4) Read-Through — cache sits in front of DB, handles population itself. (5) Refresh-Ahead — proactively refreshes cache before expiry. Cache invalidation: hardest problem. Strategies: TTL-based expiry, event-driven invalidation (write triggers cache delete). Levels: L1 (in-process, Caffeine), L2 (distributed, Redis). Eviction policies: LRU (Least Recently Used), LFU (Least Frequently Used), TTL.

✓ Strong Answer

DI is a design pattern where objects receive their dependencies from an external source (injector) rather than creating them internally. Without DI: class A creates instance of B directly — A is tightly coupled to B's implementation. With DI: A receives B through constructor/setter — A depends on B's interface, not its implementation. Three types: (1) Constructor injection (preferred) — dependencies passed at construction; object always valid; easy to test. (2) Setter injection — optional dependencies; allows mutation after construction. (3) Field injection (@Autowired directly on field) — convenient but hides dependencies, can't be used with final fields, harder to test. In Spring Boot: @Component, @Service, @Repository classes are managed beans; Spring's IoC container creates and injects them. @Autowired / constructor injection are the mechanisms. Benefit: testability — inject mock/stub in tests without touching production code.

✓ Strong Answer

HashMap uses an array of "buckets" (default 16). get(key): compute key.hashCode() → apply hash function → index into bucket array → traverse linked list/tree at bucket for equals() match. put(key, value): same hash → index → if collision: add to linked list at bucket. Collisions: two keys with same hash index land in same bucket — resolved by chaining (linked list). Java 8+: when bucket list exceeds 8 entries, converts to balanced TreeMap (O(log n) instead of O(n) for worst case). Load factor (default 0.75): when 75% of buckets are filled, resize (double array, rehash all entries). Thread safety: HashMap is NOT thread-safe. ConcurrentHashMap: uses segment locking (Java 7) or CAS + synchronized per bucket (Java 8+) for thread safety without full lock.

✓ Strong Answer

Singleton: private constructor + static instance + static getInstance() method. Double-checked locking (thread-safe, efficient): check instance is null, synchronize, check again, create. Enum singleton (Joshua Bloch recommendation): the safest Java singleton — serialisation-safe, reflection-safe. Spring Beans are singletons by default (@Scope("singleton")) — Spring manages one instance per ApplicationContext. When to avoid: (1) Global state — makes reasoning hard, any code can modify it. (2) Testability — can't replace with mock without reflection hacks. (3) Concurrency — shared mutable state requires careful synchronisation. (4) Distributed systems — "singleton" per JVM; multiple instances = no singleton. Better alternatives: Spring-managed beans (gives you DI + test overrides), or pass dependencies explicitly.

✓ Strong Answer

Cookie: a small piece of data stored in the browser, sent with every request to the same domain. Attributes: HttpOnly (JS can't read), Secure (HTTPS only), SameSite (CSRF protection). Session (server-side): server stores session data in memory/Redis; sends a session ID to the client in a cookie. Stateful — server must look up the session on every request. Scales poorly: sticky sessions or distributed session store needed. JWT (JSON Web Token): self-contained token with header.payload.signature. Server generates and signs with secret key; client stores (cookie or localStorage); server verifies signature on each request — stateless, no DB lookup. Structure: header (alg, type) + payload (claims: userId, roles, exp) + signature (HMAC-SHA256 or RSA). Trade-offs: Session — easy to revoke (delete from store). JWT — can't revoke individual tokens until expiry (use short expiry + refresh tokens). JWT payload is base64 encoded, NOT encrypted — don't store sensitive data.

✓ Strong Answer

5 categories: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), 5xx (server error). Critical codes: 200 OK (success), 201 Created (POST success, return Location header), 204 No Content (DELETE success, no body), 301 Moved Permanently (permanent redirect, browser caches), 302 Found (temporary redirect), 304 Not Modified (cache still valid), 400 Bad Request (invalid input — include error detail), 401 Unauthorized (not authenticated — misleading name), 403 Forbidden (authenticated but lacks permission), 404 Not Found, 409 Conflict (resource state conflict — e.g., duplicate email), 410 Gone (resource permanently deleted), 422 Unprocessable Entity (semantic validation error), 429 Too Many Requests (rate limit exceeded, include Retry-After header), 500 Internal Server Error (generic), 502 Bad Gateway (upstream service failed), 503 Service Unavailable (overloaded/maintenance, include Retry-After), 504 Gateway Timeout.

✓ Strong Answer

A message queue is a buffer that decouples producers from consumers. Producer writes messages; consumer reads and processes at its own pace. Key benefits: (1) Decoupling — producer doesn't need consumer to be running. (2) Load levelling — queue absorbs traffic spikes; consumer processes at sustainable rate. (3) Reliability — messages persist until consumed; consumer crash = message not lost. (4) Async processing — producer gets immediate response; slow work happens in background. Patterns: Point-to-Point (one producer, one consumer — e.g., SQS), Pub/Sub (one producer, multiple consumers — e.g., Kafka, SNS). When to use: sending emails, processing payments, video transcoding, notification delivery, data pipelines. Trade-off: adds complexity (eventual consistency, idempotency, ordering concerns, dead letter queues). Common: Kafka (log-based, replay), RabbitMQ (exchange/routing), AWS SQS (managed, at-least-once).

✓ Strong Answer

Docker solves the "works on my machine" problem by packaging an app with its complete runtime environment (code, runtime, libraries, environment variables, config) into a portable container image. Key concepts: Image: read-only template built from a Dockerfile (layers). Container: running instance of an image (isolated process). Dockerfile: build instructions (FROM base image, COPY code, RUN install deps, CMD start command). Registry: image storage (Docker Hub, ECR, GCR). Isolation: Linux namespaces (process, network, filesystem) + cgroups (CPU, memory limits). vs VM: VMs virtualise hardware (heavy, minutes to start). Containers virtualise the OS (lightweight, seconds to start, share kernel). Immutability: containers are replaced not patched — predictable deployments. Layers: Docker images use union filesystem (OverlayFS) — shared base layers reduce storage.

✓ Strong Answer

Structured answer (STAR): "At [company], we had to decide whether to migrate our payment service to a new vendor within 2 weeks — the old contract was expiring. We had incomplete load test data (only 30% of projected peak traffic tested) and no prod equivalent environment. I identified the 3 highest-risk unknowns: (1) peak throughput, (2) failover time, (3) reconciliation format. I made a risk-ranked decision: proceed with migration but deploy a feature flag that reverts to old vendor in 30 seconds if error rate spikes. Defined a clear abort criterion: >1% error rate triggers immediate rollback. The migration went live — we hit one edge case in reconciliation that we'd flagged as a risk, activated the flag, reverted, fixed the format, redeployed 4 hours later. Result: zero customer impact, migration complete on time."

✓ Strong Answer

"The team decided to implement a synchronous service-to-service call for order fulfilment notifications — I believed this created an unacceptable cascading failure risk based on previous incidents. I first made sure I fully understood their reasoning (they were optimising for simplicity and time-to-delivery). I prepared a written technical doc with: the specific failure scenario, historical incident data showing the cascading pattern, the async alternative with estimated implementation time (+2 days), and risk comparison. I presented it in the design review and proposed: 'let's implement sync now with a clear async migration ticket as P1 for next sprint.' The team agreed on the async migration. During the sprint, the sync service was knocked by a downstream timeout — no incident because the async path had already replaced it. Result: the team established async-by-default as a team principle."

✓ Strong Answer

"Our payment processing service started showing 0.3% of transactions silently failing — no exception, no error log, just missing in our reconciliation report. This happened only at specific times. Debugging process: (1) Established what 'normal' looked like from metrics (transaction rate, DB write rate, Kafka produce rate). (2) Found: DB write rate was normal, Kafka produce rate had occasional 0.1s gaps — correlated with the missing transactions. (3) Checked Kafka producer config — found max.block.ms was 100ms. Producer was silently timing out without throwing an exception because we caught Exception and logged 'produce failed' at DEBUG level. (4) Root cause: a saturation spike on our Kafka cluster caused producer backpressure; our error handling swallowed it. Fix: (1) Raise log level to WARN for produce failures. (2) Add Kafka produce error rate to dashboards. (3) Fix max.block.ms to 5000ms with proper retry. Result: zero silent failures since, and we added this to our Kafka producer checklist."

✓ Strong Answer

"I joined a team where the integration test coverage was 12% and deployments frequently caused prod incidents. Instead of just complaining, I: (1) Proposed a team-level OKR: raise test coverage to 60% and reduce deployment-related incidents by 50% in one quarter. (2) Created a testing guide (specific to our domain — not generic) with worked examples. (3) Added coverage checks to the CI pipeline — PRs with coverage regression required extra reviewer approval. (4) Led 'Test clinic' sessions (30 min Fridays) where we refactored the trickiest untested code together. (5) Recognised teammates in team meetings when they caught bugs in code review. Result: 61% coverage in 10 weeks, 0 deployment incidents that quarter (vs 4 the previous quarter). Two team members adopted this as their own practice and are now mentoring others."

✓ Strong Answer

"We needed to build an internal analytics dashboard for our ops team. I had a 2-week window, no budget for new infrastructure, and could allocate only 20% of my time. I applied the following: (1) Reused our existing PostgreSQL DB with materialized views instead of spinning up a separate analytics DB. (2) Used Chart.js (open source) instead of a paid dashboard tool. (3) Identified the 3 metrics the ops team actually needed (vs their wish list of 15). (4) Built the MVP in 3 days — deployed, got feedback, iterated. Total cost: 0 additional infrastructure. Result: ops team reduced their daily manual reporting time from 2 hours to 10 minutes. Six months later, only 4 of the original 15 metrics turned out to be needed — the frugal MVP approach prevented over-engineering."

✓ Strong Answer

"Our team caused a production incident that affected 200 merchants for 4 hours — a config change I reviewed had an untested edge case. Actions: (1) Immediate transparency: I posted a detailed incident timeline in our internal channel within 15 minutes with a clear 'we caused this, working on a fix' message — no hedging. (2) Communicated estimated resolution time with updates every 30 minutes even when there was no new information. (3) When fixed: published a COE (Correction of Errors) within 48 hours — including a section acknowledging my specific review gap. (4) Followed up with the 3 most impacted merchants directly, explained what happened and what we'd changed. Result: our NPS with affected merchants improved in the next survey. One merchant said the transparency made them MORE confident in us."

✓ Strong Answer

"Our microservice architecture had 40 services and no way to understand end-to-end data flow for compliance. Off-the-shelf tools either required SDK instrumentation in every service (3-month effort) or were too expensive. I invented: a lightweight 'shadow proxy' pattern — a sidecar that reads Kafka topics and builds a data lineage graph without touching service code. Built with: Kafka consumer + Neo4j graph DB + a simple UI showing data flow. Developed it in 3 weeks as a 20% project. Result: compliance audit completed in 2 days (was estimated 3 weeks). The pattern was adopted by 2 other teams for their own observability needs. Key insight: the existing tools assumed service code instrumentation; I inverted the assumption and listened passively instead."

✓ Strong Answer

"When our monitoring team left the company, no one owned our observability stack. I volunteered to own it despite it being outside my sprint commitments. I: (1) Took a full inventory of what existed and what was missing. (2) Identified the 3 critical gaps: no service-level alerting, no on-call runbooks, and Grafana dashboards 6 months out of date. (3) Wrote the runbooks for our 12 most common production issues. (4) Set up RED method dashboards for every service (Rate, Errors, Duration). (5) Trained 6 engineers on the alerting system. (6) Established a 'monitoring owner' rotation so ownership was sustainable. Result: mean-time-to-detect for incidents dropped from 45 min to 8 min. I still own the system 18 months later."

✓ Strong Answer

"Our deployment process had grown to 47 manual steps over 3 years, documented in a 20-page Confluence doc. Deploy time: 4 hours, required 2 engineers, and caused 1-2 incidents per month due to human error. I proposed simplifying it. Analysis: 30 of the 47 steps were workarounds for problems that no longer existed (system migrations long completed). I eliminated them. The remaining 17 I automated with GitHub Actions. The Confluence doc was replaced by a single command: ./deploy.sh --env prod. Result: deploy time: 20 minutes (12x faster), no human error incidents in 6 months, single engineer can deploy independently. The 20-page doc is now a 3-line README."

✓ Strong Answer

"I led a migration of our authentication service 2 weeks before a PCI compliance audit — a date we couldn't move. 3 days in, we discovered the new auth provider had an undocumented rate limit (1000 req/min) that would break our flash sale flows (10K req/min peak). Obstacles: (1) New vendor couldn't change the limit in time. (2) Rolling back would fail the audit. (3) Our existing caching layer didn't cover auth tokens. Actions: (1) Immediately assembled the team to generate options — we had 4 viable paths in 2 hours. (2) Chose: add auth token caching layer with 5-min TTL — reuses tokens for same user within window, reducing auth calls by 94%. (3) Built, tested, deployed in 36 hours. Result: PCI audit passed, flash sale peak handled with 98% cache hit rate. Post-mortem: added vendor rate limit discovery to our vendor evaluation checklist."

✓ Strong Answer

OAuth 2.0 is an authorisation framework (not authentication). Authorization Code Flow (most secure, for server-side apps): (1) Client redirects user to Authorization Server (e.g., Google) with: client_id, scope, redirect_uri, state (CSRF protection), code_challenge (PKCE). (2) User authenticates on Auth Server and grants consent. (3) Auth Server redirects to redirect_uri with an authorization code (short-lived, single-use). (4) Client's backend exchanges code for tokens at Token Endpoint (sends code + code_verifier). (5) Auth Server returns: access_token (short-lived, 1h), refresh_token (long-lived, 30d). (6) Client uses access_token in Authorization: Bearer header for API calls. (7) On expiry: use refresh_token to get new access_token. PKCE (Proof Key for Code Exchange): prevents authorization code interception — required for public clients (SPAs, mobile apps). Scopes: define what access is granted (openid, profile, email, read:user).

✓ Strong Answer

Implementation: (1) Dependency: spring-boot-starter-security + jjwt-api. (2) JwtService: generate tokens (Jwts.builder() + HMAC-SHA256 or RS256 signing), validate tokens (parse + verify signature + check expiry), extract claims. (3) JwtAuthFilter extends OncePerRequestFilter: extract Bearer token from Authorization header → validate → load UserDetails → set SecurityContextHolder. (4) SecurityConfig: add JwtAuthFilter before UsernamePasswordAuthenticationFilter, disable session creation (SessionCreationPolicy.STATELESS), disable CSRF (stateless APIs). (5) /login endpoint: authenticate with UsernamePasswordAuthenticationToken → generate JWT → return. Token structure: header (alg:HS256) + payload (sub, roles, iat, exp) + signature. Refresh: short-lived access token (15 min) + long-lived refresh token (7d) stored in HttpOnly cookie.

✓ Strong Answer

CSRF (Cross-Site Request Forgery): an attacker tricks an authenticated user's browser into making an unwanted request to your site. Example: user is logged into bank.com (session cookie auto-sent). Attacker's evil.com has a hidden form POST to bank.com/transfer. User visits evil.com → browser sends the POST with the bank.com session cookie → bank processes it. Defence — Synchronizer Token Pattern: server embeds a secret CSRF token in each form. POST must include the token in the request body (not auto-sent by browser). Spring Security auto-generates and validates CSRF tokens for all state-changing requests. For REST APIs: stateless JWTs are NOT vulnerable to CSRF (no cookies auto-sent) — disable CSRF in Spring Security for JWT APIs. SameSite cookie attribute: SameSite=Strict/Lax prevents browsers from sending cookies on cross-site requests — modern defence that doesn't require tokens.

✓ Strong Answer

Options (increasing security): (1) Network-level: VPC/private subnet — services only reachable within the network. Still needs auth for lateral movement. (2) JWT propagation: API Gateway validates external JWT, issues internal JWT for service-to-service. Services validate internal JWT (same auth service). (3) mTLS (mutual TLS): both client and server present certificates and verify each other. Unlike regular TLS (server only presents cert), mTLS authenticates both endpoints. Each service has a certificate issued by an internal CA. The certificate IS the identity. Service mesh (Istio/Linkerd): injects a sidecar proxy (Envoy) next to each service. Sidecar handles: mTLS automatically (no app code changes), circuit breaking, observability (traces), traffic management. The app only talks to localhost; the sidecar handles all network security. SPIFFE/SPIRE: provides workload identity — issues short-lived X.509 certificates to services based on their Kubernetes service account.

✓ Strong Answer

Spring Security's security filter chain is a series of servlet filters (implementations of javax.servlet.Filter) that process every incoming HTTP request in order. Key filters (in order): (1) DisableEncodeUrlFilter — prevents session ID in URLs. (2) SecurityContextPersistenceFilter — loads SecurityContext from session (stateful) or creates empty context (stateless). (3) CsrfFilter — validates CSRF token for state-changing requests. (4) LogoutFilter — intercepts logout URL. (5) UsernamePasswordAuthenticationFilter — processes form login. (6) JwtAuthFilter (custom) — validates JWT, sets SecurityContext. (7) ExceptionTranslationFilter — converts Spring Security exceptions to HTTP responses (401/403). (8) FilterSecurityInterceptor — final access control check against @PreAuthorize / HttpSecurity config. SecurityContextHolder: thread-local storage of the current Authentication object (Principal + credentials + authorities). Principal = currently authenticated user. Multiple SecurityFilterChains: Spring Security 5.7+ supports multiple chains — different config for /api/** vs /admin/**.

✓ Strong Answer

OWASP Top 10 2021: (1) Broken Access Control — most common. User can access other users' data or perform admin actions. Fix: server-side enforcement of @PreAuthorize, never trust client-sent user IDs. (2) Cryptographic Failures — sensitive data exposed (PII, passwords, payment data). Fix: encrypt at rest + in transit, bcrypt passwords (never MD5/SHA1 for passwords). (3) Injection (SQL, LDAP, Command) — malicious data executed as code. Fix: parameterised queries / JPA (never string concatenation), input validation. (4) Insecure Design — architectural security gaps. Fix: threat modelling, security in design not as afterthought. (5) Security Misconfiguration — default credentials, verbose error messages, open cloud buckets. Fix: spring-boot-actuator secured, no stack traces in prod responses. (6) Vulnerable Components — outdated dependencies with known CVEs. Fix: dependabot / OWASP dependency check in CI. (7) Authentication Failures — weak passwords, brute force. Fix: rate limiting on auth, strong password policy, MFA. (8) Integrity Failures — CI/CD pipeline compromise, insecure deserialization. (9) Logging/Monitoring Failures — breaches not detected. Fix: centralized logging, alerting on auth failures. (10) SSRF — server-side request forgery. Fix: whitelist external URLs, block internal metadata endpoints.

✓ Strong Answer

RBAC: assign users to roles, assign permissions to roles, check role at runtime. Spring implementation: (1) UserDetails.getAuthorities() returns roles (ROLE_ADMIN, ROLE_USER). (2) @PreAuthorize("hasRole('ADMIN')") on methods. (3) HttpSecurity.requestMatchers("/admin/**").hasRole("ADMIN"). (4) Custom: grant specific permissions (not just roles) — hasAuthority("user:write"). Hierarchical roles: ROLE_ADMIN inherits ROLE_USER with RoleHierarchy bean. ABAC (Attribute-Based Access Control): access based on attributes of user, resource, and environment. Example: a user can edit a document if: user.department == document.department AND user.clearanceLevel >= document.classification AND time.current is within business hours. Spring Security: @PreAuthorize("@documentSecurity.canEdit(authentication, #docId)") — calls a Spring bean for complex logic. When RBAC is insufficient: multi-tenant systems (tenant A can't see tenant B's data), row-level security (user sees only their own orders), time-based access, geographic restrictions.

✓ Strong Answer

SQL injection: attacker inserts SQL into user input that gets executed as a query. Classic example: SELECT * FROM users WHERE username=&#39;[input]&#39; — if input is "admin&#39;--", the query becomes SELECT * FROM users WHERE username=&#39;admin&#39;--&#39; (rest commented out — authentication bypassed). Parameterised queries (PreparedStatement): the driver sends query structure and parameters separately — parameters are NEVER interpreted as SQL. JPA protects by default: Spring Data JPA repository methods (findByUsername(String username)) use parameterised queries automatically. @Query("SELECT u FROM User u WHERE u.email = :email") — also parameterised. JPQL is safe — JPA handles parameterisation. Vulnerable pattern: @Query(value = "SELECT * FROM users WHERE username = &#39;" + username + "&#39;", nativeQuery = true) — native query with string concatenation. Also vulnerable: JdbcTemplate with string concatenation (use "?" placeholders instead). Hibernate Criteria API and QueryDSL are also injection-safe.

✓ Strong Answer

NEVER use MD5 or SHA-1/256/512 for passwords. Why: these are fast — an attacker with the hash can try billions of combinations per second (GPU-accelerated). A 6-character password breaks in milliseconds. Correct approach: purpose-built slow hashing algorithms. (1) bcrypt — adaptive cost factor (rounds), built-in salt. Standard choice. Spring Security default: BCryptPasswordEncoder. (2) Argon2 — winner of Password Hashing Competition 2015. Memory-hard — resistant to GPU attacks. Spring: Argon2PasswordEncoder. (3) PBKDF2 — NIST-approved, used in FIPS environments. Avoid: MD5, SHA-*, plain text, reversible encryption (password is not a secret you need to recover — it only needs to be verified). Spring Boot implementation: @Bean PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(12); } — factor 12 means 2^12 rounds. Salting: bcrypt generates a unique random salt per password — same password produces different hashes. Verification: passwordEncoder.matches(rawPassword, storedHash) — never decrypt.

✓ Strong Answer

Rate limiting controls the frequency of requests. Algorithms: (1) Token Bucket — bucket holds N tokens, refills at rate R/sec. Each request consumes a token. Best for: allowing short bursts, smooth long-term rate. Redis-backed implementation. (2) Sliding Window Log — track exact timestamps of recent requests. Accurate but memory-intensive. (3) Fixed Window Counter — count requests per fixed time window (1 min). Simple, but edge bursts (2x rate at window boundary). (4) Leaky Bucket — requests processed at fixed rate, excess queued or dropped. Best for: smoothing bursty traffic. Spring Boot implementation: (1) Resilience4j RateLimiter: @RateLimiter(name = "api") on methods. Config: limitForPeriod=100, limitRefreshPeriod=1s. (2) Bucket4j with Redis: for distributed rate limiting across multiple instances. (3) Spring Cloud Gateway: built-in Redis rate limiting filter. Granularity: per IP, per user, per API key, per endpoint. Response: 429 Too Many Requests + Retry-After header + X-RateLimit-Limit/Remaining/Reset headers.