Backend Developer Interview Prep Guide

This is a top question at Stripe and Cloudflare. Discuss token bucket vs sliding window log vs sliding window counter algorithms. For distributed rate limiting, explain using Redis with atomic INCR and EXPIRE operations. Cover: how to handle Redis failures (fail open vs fail closed), the tradeoff between accuracy and performance, returning proper HTTP 429 responses with Retry-After headers, and different tiers for free vs paid users. Discuss how Stripe actually uses a combination of token bucket per user and global rate limiting.

This is a real Amazon and Stripe interview question. Cover: idempotency keys for exactly-once processing, saga pattern or two-phase commit for distributed transactions, event sourcing for complete audit trail, dead letter queues for failed transactions, PCI DSS compliance considerations, and webhook delivery to merchants with retry logic. Discuss the tradeoff between synchronous (user waits) vs asynchronous (eventual confirmation) processing.

Go beyond textbook definitions. Give real examples: DynamoDB defaults to eventually consistent reads (cheaper, faster) but offers strongly consistent reads at 2x cost. PostgreSQL with synchronous replication gives strong consistency but higher write latency. Discuss specific scenarios: a shopping cart can tolerate eventual consistency (brief stale reads), but an inventory counter for the last item in stock needs strong consistency to prevent overselling. Mention Cassandra tunable consistency levels and how QUORUM reads/writes provide a middle ground.

This is a harder system design question asked at Google. Cover the two main approaches: Operational Transformation (OT, used by Google Docs) and Conflict-free Replicated Data Types (CRDTs, used by Figma). Discuss: WebSocket connections for real-time sync, operation ordering and conflict resolution, cursor presence tracking, version history with snapshots, and scaling the collaboration service horizontally. You do not need to implement OT or CRDTs, but explain the tradeoffs: OT requires a central server, CRDTs work in peer-to-peer but have higher memory overhead.

Show systematic debugging: start with distributed tracing (Jaeger/Datadog) to identify which service or database call is slow. Check: N+1 queries (common culprit), missing database indexes, connection pool exhaustion, downstream service timeouts, garbage collection pauses, and lock contention. Solutions: add indexes based on EXPLAIN ANALYZE, implement read-through caching with Redis, add connection pooling (PgBouncer), optimize queries with JOINs instead of multiple round trips, and add circuit breakers for slow dependencies.

Design RESTful resources: /users, /posts, /comments with proper HTTP verbs, pagination (cursor-based), filtering, and error responses. Then discuss GraphQL tradeoffs: GraphQL solves over-fetching (mobile clients get exactly what they need) but introduces complexity in caching (no HTTP caching), authorization (field-level permissions), and N+1 queries (use DataLoader). REST is better for simple CRUD APIs with well-defined clients; GraphQL shines for complex data graphs with diverse clients. Mention that many companies (Shopify, GitHub) use both.

Discuss the expand-and-contract pattern: first add the new column (nullable or with default), deploy code that writes to both old and new columns, backfill existing data, deploy code that reads from the new column, then drop the old column. Cover: migration testing in staging with production-like data, rollback strategies, using tools like Flyway or Alembic for version control, locking considerations (avoid full table locks on large tables), and online DDL tools like pt-online-schema-change for MySQL or pg_repack for PostgreSQL.

Be specific and data-driven. For example: "I noticed our order processing pipeline was taking 12 seconds for large orders. Using Datadog APM, I traced it to sequential API calls to our inventory service, one per line item. I implemented batch API endpoints and parallel processing, reducing the time to 800ms. The change improved our checkout completion rate by 8% and reduced timeout errors by 95%." Show the investigation method, not just the fix.