Backend Development Background and Motivation Questions

Articulate your journey into backend development and why you prefer server side concerns over other areas. Highlight specific backend projects, responsibilities you owned such as API design, database modeling, scaling and performance work, infrastructure or DevOps involvement, and tradeoffs you made. Demonstrate familiarity with backend principles such as data consistency, caching, reliability, and observability and explain how your background prepared you to solve those problems. Provide concrete examples and outcomes that show technical competence and domain motivation.

HardSystem Design

68 practiced

Design a distributed cache invalidation mechanism for a geo-distributed service with caches in multiple regions. Explain approaches to ensure reasonable freshness without sacrificing availability: TTL-based eviction, explicit invalidation messages via a broker, causal ordering, use of versioned keys, and strategies to recover from missed invalidations. Discuss tradeoffs between staleness, consistency, and complexity.

Sample Answer

**Clarify goals & constraints**- Global reads in multiple regions, low-latency, high availability, acceptable bounded staleness (e.g., seconds), occasional strong-consistency paths for sensitive data. Network partitions expected.

**High-level options (tradeoffs summary)**- TTL-only: simple, highly available, but higher staleness and wasted stale reads during TTL window.- Broker-based explicit invalidations: low staleness, more complex, depends on broker delivery/latency.- Causal ordering + versioned keys: ensures monotonic reads and avoids reordering anomalies.- Recovery strategies: reconciliation, lazy validation, read-through misses, and fallbacks to origin.

**Design components**1. Versioned keys - Store cache entries as key@version (or include a monotonic vector/epoch). Writers bump version atomically in origin DB or coordination service. - Reader uses version metadata to detect stale entries.

2. Invalidation propagation via broker - Origin publishes invalidation messages (key, new-version, timestamp) to a global pub/sub (e.g., Kafka with geo-replication or a multi-region SNS+SQS). - Each regional cache subscribes; on receipt, invalidate or update local entry if version older. - Use compacted topic so new subscribers catch current versions.

3. Causal ordering - Include causal metadata (simple logical clock or Lamport timestamp per key) to prevent out-of-order invalidations. Broker partitions by key to preserve ordering.

4. TTL hybrid - Keep short TTL as safety net (e.g., few seconds). Primary freshness via invalidations, TTL prevents permanent staleness after missed messages.

5. Recovery from missed invalidations - Compacted topic replay on restart. Periodic reconciliation: region polls origin diffs (list of keys modified since timestamp) or queries a changelog API. - On cache miss or detected stale version, read-through to origin and update cache. - Monitoring/metrics for broker lag and reconciliation failures; alert on high staleness.

**Availability vs consistency tradeoffs**- TTL-only: maximizes availability, minimal complexity, worst staleness.- Broker + versioning: strong operational consistency (bounded staleness), moderate complexity and dependence on messaging reliability.- Causal/versioning: reduces anomalies, slightly more metadata and coordination.- Strong consistency (synchronous invalidation before write acknowledges): high consistency, increased latency and reduced availability during partitions.

**Practical recommendation for Backend Developer**- Implement versioned keys + broker invalidations + short TTL fallback.- Partition broker by key for ordering, use compacted topic or CDC stream from primary DB.- Expose a read-through path to origin and periodic reconciliation.- Instrument latencies and staleness; tune TTL and retry windows based on SLOs.

MediumSystem Design

120 practiced

Design a RESTful API for a multi-tenant note-taking application that supports creating, editing, deleting, and sharing notes across users and tenants. Define endpoints and sample request/response shapes, explain your tenant isolation strategy, authentication model, rate-limiting approach, and database choice. Explain tradeoffs between a shared schema, tenant-id columns, and per-tenant databases and how you'd test tenant isolation.

Sample Answer

**API Endpoints (RESTful)**- POST /v1/tenants/{tenantId}/notes — create note- GET /v1/tenants/{tenantId}/notes/{noteId} — read note- PUT /v1/tenants/{tenantId}/notes/{noteId} — update- DELETE /v1/tenants/{tenantId}/notes/{noteId} — delete- POST /v1/tenants/{tenantId}/notes/{noteId}/share — share with user(s)- GET /v1/users/{userId}/shared-notes — notes shared to user

Sample create request/response:

json

POST /v1/tenants/tn-123/notes
Authorization: Bearer <JWT>
{
  "title":"Quarterly Plan",
  "content":"... ",
  "visibility":"private" // private|tenant|shared
}

json

201 Created
{
  "id":"n-456",
  "tenantId":"tn-123",
  "ownerId":"u-1",
  "title":"Quarterly Plan",
  "visibility":"private",
  "createdAt":"2026-02-28T12:00:00Z"
}

**Tenant isolation strategy**- Primary: shared application, tenant-id column on records plus Row Level Security (RLS) in PostgreSQL to enforce row access by tenant_id from authenticated token.- RLS provides strong DB-enforced isolation while keeping single schema for operational simplicity.

**Authentication & authorization**- OAuth2 / JWT access tokens issued by Identity Provider (Auth0 / Cognito). JWT includes tenant_id, user_id, roles, scopes.- Backend verifies signature, then set DB session parameter (e.g., SET app.current_tenant = 'tn-123') so RLS policies use it.- Sharing: ACL table note_shares(note_id, grantee_user_id, permissions) validated in queries.

**Rate limiting**- Per-tenant and per-user rate limits using Redis token-bucket. Keys: rl:tenant:{tenantId} and rl:user:{userId}. Different quotas (tenant higher). Burstable with refill.

**Database choice**- PostgreSQL primary (ACID, RLS, strong relational joins for ACLs). Use read replicas for scaling reads. Use S3 for large attachments and store pointers in DB.

**Trade-offs**- Shared schema with tenant_id column: simple, low operational cost, efficient cross-tenant queries (if needed) but needs careful indexing and RLS for safety.- Per-tenant schema: better logical separation, easier migrations per-tenant, but schema drift and more maintenance; limited when tenants count grows.- Per-tenant DB: strongest isolation and customizable tuning/compliance, higher cost, complex orchestration and backups.Choice rationale: start with shared schema + RLS; move to per-tenant DB for high-risk or large tenants.

**Testing tenant isolation**- Automated tests that: - Generate tokens for tenant A and tenant B, attempt CRUD on same note IDs and assert 403/404 as appropriate. - Integration tests that set DB session tenant and verify RLS blocks cross-tenant reads/writes. - Fuzz tests / property tests to attempt SQL injections or manipulated tenant claims. - Chaos test by replacing JWT tenant_id with another and confirming enforcement.- CI adds static policy checks and periodic pen-tests.

Trade-offs and practical choices prioritized: developer velocity, security (RLS+JWT), scalability (replicas + Redis), and upgrade path to stronger isolation for specific tenants.

MediumTechnical

97 practiced

Sketch an end-to-end observability plan for a microservice architecture. Specify the SLIs and SLOs you would define, the key metrics (latency, error-rate, throughput, saturation), tracing spans to instrument, structured logging formats and correlation IDs, alerting thresholds, and how you’d use these signals to prioritize fixes and communicate reliability to stakeholders.

Sample Answer

**Overview (role: Backend Developer)** I’d deliver an end-to-end observability plan covering SLIs/SLOs, metrics, tracing, logs, alerts, and stakeholder reporting so teams can detect, diagnose, and prioritize reliability work.

**SLIs & SLOs**- Availability SLI: % of successful production requests (2xx/3xx) per service. SLO: 99.9% monthly.- Latency SLI: P95 end-to-end request latency. SLO: P95 < 300 ms.- Error-rate SLI: % of requests returning 5xx. SLO: < 0.1% daily.- Throughput SLI: requests/sec (capacity planning). SLO: sustain expected traffic ±10%.

**Key metrics to collect**- Latency: P50, P95, P99, histogram buckets for request duration.- Error-rate: 4xx vs 5xx counts, exception classes.- Throughput: rps, requests per endpoint.- Saturation: CPU%, memory%, DB connection pool usage, queue lengths.

**Tracing & Spans**Instrument:- Ingress API gateway span- Auth validation span- Handler/controller span per endpoint- DB query span (including SQL + rows returned)- External HTTP/gRPC call spans- Cache (Redis) get/set spansInclude tags: user_id, request_id, tenant_id, route, status_code, db.table.

**Structured logging & correlation**Use JSON logs with consistent fields:

json

{
  "timestamp":"2026-01-01T12:00:00Z",
  "level":"ERROR",
  "service":"orders",
  "env":"prod",
  "request_id":"req-12345",
  "user_id":"u-678",
  "trace_id":"abcd-ef01",
  "span_id":"span-02",
  "msg":"failed to write order",
  "error":"PG: duplicate key",
  "latency_ms":420
}

Propagate request_id and trace_id across services; prefer W3C traceparent.

**Alerting thresholds**- Page (urgent): Availability SLO burn rate > 4x for 1h OR errors >1% global 5xx for 5m.- Pager: P95 latency breach > 2x SLO sustained 10m.- Ops/Slack: DB connection pool > 80% for 10m, queue backlog > threshold.Use burn-rate alerts tied to SLO windows to avoid noisy symptom-only alerts.

**Prioritization & workflow**- Triage by SLI impact: failures affecting SLOs (availability/latency) get high priority.- Use error budget: If error budget exhausted, freeze risky releases and prioritize fixes.- Root-cause via traces + logs: correlate trace_id to pull spans and logs; use histogram to find regressions.- Postmortem: quantify SLO impact (minutes of downtime, % error budget used), RCA, action items.

**Communicating reliability**- Weekly dashboard for engineering: SLO status, burn rate, top offenders (endpoints/services).- Monthly summary for stakeholders: uptime %, incidents, business impact, roadmap items.- Present mitigation plan when SLOs are near breach and use error-budget-driven decisions for releases.

EasyBehavioral

96 practiced

Tell me about your journey into backend development and why you chose server-side work. Include early influences, the first backend project you shipped, the languages and frameworks you used, the responsibilities you owned (API design, database schema, deployments, monitoring), and how those experiences shaped your interest in scalability, reliability, or infrastructure. Where possible, cite concrete outcomes or metrics that demonstrate impact.

EasyTechnical

74 practiced

How do you approach authentication and authorization when designing a new API? Discuss token strategies (JWT vs opaque tokens), session management, role-based versus attribute-based access control, refresh tokens and token revocation, key rotation, and common mitigations against attacks like replay or token theft. Mention any frameworks or standards (OAuth2, OpenID Connect) you used.

Unlock Full Question Bank

Get access to hundreds of Backend Development Background and Motivation interview questions and detailed answers.

Join thousands of developers preparing for their dream job.