Software Engineer interview questions

I would keep redirects on a cache-first read path and generate keys without a central bottleneck.

• A Base62-encoded 64-bit Snowflake ID gives roughly 11-character keys; worker IDs are leased uniquely and clock rollback stops generation before it can duplicate a key.
• Cassandra stores key, destination, owner, and expiry across 256 virtual shards, while Redis caches hot mappings with a 24-hour TTL.
• Redirect nodes perform one Redis lookup and then a shard lookup, leaving about 20 ms for storage inside the 100 ms p99 budget.
• Five years at 20,000 writes per second is about 3.2 trillion rows; at 100 bytes each and replication factor 3, I would budget roughly 1 PB before compaction and backups.

I would separate socket ownership from durable message processing and order messages by room.

• Stateless WebSocket gateways hold about 50,000 connections each and publish authenticated messages to Kafka keyed by room_id.
• Kafka gives one ordered partition per room key, and consumers persist messages to Cassandra before publishing them through Redis Streams to recipient gateways.
• The 200 ms p99 is measured to an online recipient gateway: 30 ms for ingress, 80 ms for Kafka plus persistence, 60 ms for fan-out, and 30 ms margin.
• Each connection has a 16 KB outbound buffer under a per-gateway 1 GB cap; on overflow a slow client gets a resync cursor and disconnects.

I would keep file bytes in object storage and make the application own only metadata and upload coordination.

• The API creates an S3 multipart upload and returns signed URLs for 16 MB parts, so a 5 GB file resumes from the last confirmed part.
• PostgreSQL stores file versions, hashes, ownership, and the multipart upload ID, with a unique constraint on tenant_id plus path plus version.
• Clients send S3's SHA-256 checksum for each part and a final manifest; S3 validates bytes before the server atomically publishes the new version.
• Ten petabytes stays in S3 with lifecycle tiers, while change notifications use a per-user monotonic cursor so offline clients request only missed metadata.

I would evaluate flags inside each process from a versioned local snapshot.

• A control-plane API stores each definition and an outbox row in one PostgreSQL transaction; CDC then publishes every committed version to Kafka.
• SDKs keep an immutable in-memory map and swap the whole snapshot atomically, making each evaluation an O(1) lookup under 1 ms.
• A streaming gRPC channel pushes versioned deltas, a gap triggers an immediate snapshot fetch, and 2-second heartbeats enforce the 5-second SLO for connected healthy SDKs.
• If the control plane is unavailable, SDKs use the last valid snapshot and a typed hard-coded default rather than blocking application requests.

I would make PostgreSQL enforce one active owner per seat and treat the hold as an expiring state.

• A conditional UPDATE claims a free or expired seat and writes hold_id plus expires_at in one transaction, so check and reserve cannot race.
• The seat row is the serialization point, and an index on event_id plus expires_at lets cleanup find expired holds without scanning the event.
• A durable timer table and scheduler publish hold_id at expiry; release runs only WHERE hold_id matches and expires_at has passed, so an old timer cannot clear a newer hold.
• The API accepts an idempotency key for 24 hours, so client retries return the original hold instead of consuming another seat.

I would use fan-out on write for normal accounts and fan-out on read for celebrity posts.

• Normal posts are pushed through Kafka into per-user Cassandra feed rows capped at the newest 1,000 item IDs.
• Accounts above 100,000 followers are marked as celebrities, and their posts stay in a separate author timeline to avoid 50 million writes per post.
• The read service scans the paged followed-celebrity index until a heap proves the top 20 cutoff, avoiding a fixed author cap that could omit posts.
• I budget 40 ms for timeline reads, 60 ms for merge and ranking, 60 ms for hydration, and retain 40 ms inside the 200 ms p95 target.

I would serve a compact prefix index entirely from memory and rebuild it off the request path.

• An offline Spark job produces a weighted finite-state transducer from the 5 million phrases, including locale and popularity scores.
• Each stateless node memory-maps the versioned index and returns the top 10 completions without a remote database call.
• A load balancer spreads traffic across 180 nodes at roughly 5,600 QPS each; after losing 1 of 3 zones, the remaining nodes stay near 8,400 QPS under a tested 10,000-QPS ceiling.
• A Redis overlay holds trending phrases for 5 minutes; the service merges that small set with the immutable index inside the 50 ms p99 budget.

I would use a partitioned log for ingestion and a columnar time-series store for compressed queries.

• Kafka absorbs about 10 GB per second across 1,500 partitions, keyed by tenant and metric hash to keep average partition ingress below 7 MB/s.
• Consumers batch 10,000 samples into ClickHouse MergeTree tables; 30 days is about 26 PB raw before compression, so replicas are partitioned by day and ordered by tenant_id, metric_id, and timestamp.
• Materialized views pre-aggregate by service into 10-second and 5-minute buckets, so a 24-hour service chart scans thousands of rows instead of all underlying series.
• Cardinality quotas reject tenants above 1 million active series, because unbounded labels would break both the 30-day storage budget and 10-second query SLO.

I would partition jobs by due-time bucket and let workers lease batches independently.

• PostgreSQL partitions jobs by hour with an index on next_run_at, while 60 logical shards keep each minute's scan bounded.
• Scheduler nodes use SELECT FOR UPDATE SKIP LOCKED to lease 1,000 due jobs for 2 minutes and publish them to Kafka.
• Workers require an execution_id and store completion with the business effect when both share a database; external effects require an idempotency key and outbox.
• A reconciliation scan finds jobs overdue by more than 2 minutes, and scheduling lag above 60 seconds breaches the stated precision target.

I would keep one durable sequence and one in-flight delivery per destination, including during retries.

• Kafka ingress uses destination_id as the key across 1,000 partitions, and a Kafka Streams state store keeps each destination's ordered pending queue.
• A dispatcher sends only the head item; 20,000 async connections sustain 200,000 per second only at measured latency near 100 ms, while 3 seconds is a cutoff, not sizing input.
• Failure moves the head's next_attempt_at through 1-minute, 5-minute, and 30-minute delays for up to 24 hours without advancing that destination.
• After 5 failures its circuit opens, but only that key waits in the partitioned state store, so healthy destinations on the same partition continue.

I would split around business ownership and transactional invariants, not around technical layers.

• Catalog owns products and prices, Inventory owns reservations, Orders owns purchase state, and Payments owns provider interactions and its ledger.
• Each service exposes versioned gRPC commands and Kafka events, and the hard no-shared-table rule is enforced with separate PostgreSQL schemas and credentials.
• Checkout orchestrates the workflow but never edits another service's rows; it calls ReserveInventory and AuthorizePayment using explicit request IDs.
• Weekly release independence is tested by consumer-driven contracts in CI, while cross-service changes remain additive for at least two releases.

I would make upload and processing separate asynchronous resources.

• The client uploads directly to S3 through multipart signed URLs, so the API never buffers a 500 MB body.
• POST /jobs validates the object metadata, records a job in PostgreSQL, and returns 202 plus a job_id within the 2-second limit.
• Kafka only wakes workers; a worker claims a 20-minute PostgreSQL lease with heartbeats and a fencing version before processing in an isolated pool.
• GET /jobs/{id} and a completion webhook expose status, while cancellation is best-effort because a 15-minute codec step may not stop instantly.

I would require an idempotency key and bind it to both the caller and request payload.

• PostgreSQL stores tenant_id, idempotency_key, request_hash, order_id, status, and response under a unique tenant-key constraint.
• The first request creates the idempotency row and order in one transaction; a duplicate returns the stored status and response.
• Reusing the same key with a different request hash returns 409, preventing an accidental collision from silently changing meaning.
• Records live for 24 hours as promised, and in-progress duplicates poll the original operation rather than running order creation concurrently.

I would keep existing versions additive and run breaking changes as an explicit migration program.

• OpenAPI schemas reject removed fields, narrowed enums, and newly required properties in CI through a tool such as oasdiff.
• A breaking change gets a dated version, while the old version remains on the same reliable gateway for the full 12-month window.
• Per-client version metrics identify the remaining 10,000 integrations, and automated notices include the exact endpoint and last-use timestamp.
• The gateway supports both versions from one canonical domain model, avoiding a separate legacy fleet that would threaten the 99.99% availability target.

I would expose opaque keyset cursors over a stable unique ordering.

• Records are ordered by created_at plus id, backed by a composite B-tree index in PostgreSQL.
• The cursor encodes the last pair and filter hash, signed with HMAC so clients cannot alter position or reuse it with different filters.
• Each page executes a range query with LIMIT 101, returning 100 rows and a next cursor without scanning prior pages.
• Inserts after the cursor may appear later in the current traversal, while inserts before it wait for a new traversal; snapshot consistency would require an as-of token.

I would make the new field optional and preserve old event meaning for the full mixed-version period.

• Avro schemas live in Schema Registry with FULL_TRANSITIVE compatibility, so old consumers read new data and new consumers can replay retained old data.
• delivery_window is a nullable record with explicit default null and documented UTC semantics; absence means no promised window rather than a guessed value.
• Producers dual-populate old and new representations for 6 months if existing fields cannot express the new concept cleanly.
• Contract fixtures run against all 40 consumers, and removal starts only after consumer-owned version telemetry shows zero old-schema reads.

I would use an orchestrated saga with explicit reservations and compensations.

• The orchestrator persists a state machine in PostgreSQL and calls all three providers with stable operation IDs and 9-second deadlines.
• Flight and hotel create 5-minute holds, while payment authorizes but does not capture until both holds succeed.
• Any failed step triggers idempotent compensation, releasing holds and voiding authorization, with retries through a durable queue.
• At 30 seconds the API returns confirmed, rejected, or pending with a booking_id; it never claims failure while compensation or a late provider response is unresolved.

I would use an append-only double-entry ledger with balances derived from immutable postings.

• PostgreSQL accepts postings only through a stored procedure with a deferred constraint trigger that verifies debits equal credits before commit.
• Account entries are partitioned monthly and indexed by account_id plus sequence, while closed partitions move to cheaper storage after one year.
• A balance table is updated in the same transaction for fast reads, and a nightly recomputation verifies it against immutable entries.
• Corrections use reversing entries linked to the original, preserving the 7-year audit trail and the hard no-mutation rule.

I would keep recent samples in a time-partitioned columnar store and archive compressed partitions to object storage.

• Kafka receives samples keyed by device_id, and ClickHouse batches inserts into daily MergeTree partitions ordered by device_id and timestamp.
• Thirty hot days at 3 million samples per second require compression and replication; Delta or Parquet files in S3 hold months 2 through 24.
• A device-hour query uses the primary ordering to scan one narrow range, while hourly min-max-avg projections serve common dashboards.
• Late samples remain writable for 48 hours; older corrections go to a side table to avoid rewriting multi-terabyte archived partitions.

I would store adjacency lists by user and precompute the small relationship checks needed online.

• Cassandra rows keyed by follower_id hold sorted followee IDs, distributing 2 billion append-heavy edges without cross-node transactions.
• A reverse table keyed by followee_id supports follower pages; both writes carry the same edge version and are repaired asynchronously.
• A Redis set caches follows for active users, so mutual status is two SISMEMBER operations well under 100 ms.
• Full mutual lists use intersection only for users below 100,000 edges; celebrity accounts use a precomputed mutual subset to cap memory and CPU.