Rust Developer interview prep

Rough estimates that will shape the architecture. Calculate out loud and round aggressively.

What to estimate:

• QPS (queries per second): average and peak (peak ≈ 2-3× the average).
• Data volume: size of one record × number of records × retention horizon.
• Read/write ratio (read:write) — determines whether you need read replicas and a cache.
• Bandwidth: QPS × response size.
• Storage: growth per year.

Handy numbers for mental math:

Quantity	Value
Seconds in a day	~86,400 ≈ 10⁵
Month	~2.5M seconds
1M requests/day	≈ 12 QPS on average
1B requests/day	≈ 12,000 QPS

Example calculation (URL shortener): 100M new links/month → 100M / 2.5M sec ≈ 40 writes/sec. Read:write = 100:1 → 4000 reads/sec. Record size ~500 bytes → 100M × 500B = 50 GB/month → 600 GB/year → ~6 TB over 10 years.

💡 State the conclusion from the numbers right away: "40 writes/sec is easy for a single DB. 4000 reads/sec — we'll add a cache and read replicas."

Describe the service contract — this pins down the functionality and helps the interviewer understand the model. REST/gRPC, the main endpoints:

POST /api/v1/urls           {long_url, custom_alias?, ttl?} -> {short_url}
GET  /{short_key}           -> 301/302 redirect

Talk through: methods, parameters, idempotency (is POST idempotent?), pagination for lists (cursor-based, not offset on large data sets), authorization (api_key / token).

• Describe the key entities and relationships (tables / collections).
• Choose the database type and justify it:
  • SQL (Postgres, MySQL): complex relationships, transactions, strong consistency, analytical queries, JOINs. Take it by default unless there's a reason not to.
  • NoSQL key-value / wide-column (DynamoDB, Cassandra): huge write scale, a simple key-based access pattern, horizontal sharding out of the box, eventual consistency.
  • Document (MongoDB): flexible schema, nested documents.
  • In-memory (Redis): cache, counters, rate limiting, queues, leaderboards.
• Think about the shard key right away (what you partition by).

Describe in words (or with a diagram) the components and the request flow:

[Client] -> [DNS] -> [Load Balancer] -> [API / App Servers (stateless)]
                                              |-> [Cache (Redis)]
                                              |-> [Database (+ read replicas)]
                                              |-> [Message Queue] -> [Workers]
                                         [CDN] -> [Blob Storage (S3)]

Trace a typical request along this path from the client all the way to the DB and back.

• LB distributes traffic across instances (round-robin, least-connections, consistent hashing). It enables horizontal scaling and fault tolerance (removing dead nodes via health checks).
• L4 (TCP) is faster; L7 (HTTP) can route by URL/headers and do TLS termination.
• Reverse proxy (Nginx, Envoy): TLS termination, compression, caching, backend protection, a single entry point.
• 💡 Keep applications stateless — then the LB can send a request to any instance. Sessions go in Redis, not in process memory.