Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Mercor Interview Preparation Guide

​

1. Database Design & Architecture

​

Core Design Principles

1. Data Flow Mapping: Map user actions to CRUD operations and plan transaction boundaries. Identify which operations need strong consistency (payments, inventory) vs. eventual consistency (notifications, analytics).
2. Schema Design: Normalize data to reduce redundancy and design efficient indexes. But know when to denormalize — read-heavy dashboards with complex joins are a classic case where denormalization saves you from slow aggregation queries at the cost of write complexity.
3. Scalability: Choose between read-replicas, sharding, or microservices patterns. The decision depends on your read/write ratio, data locality requirements, and whether your bottleneck is query throughput or storage volume.

​

2. System Design: Load Balancing

​

Algorithms

• Round Robin: Sequential distribution. Simple and stateless. Works well when all servers are identical and requests are roughly equal in cost. Falls apart when some requests are 10x more expensive than others (e.g., a report generation endpoint vs. a health check).
• Weighted Round Robin: Routes more traffic to more powerful servers. Useful in heterogeneous fleets or during rolling deployments where new instances are warming up.
• Least Connections: Routes to the server with the fewest active connections. Best for long-lived connections (WebSockets, gRPC streams) or when request processing times vary significantly.
• IP Hash: Ensures a user always hits the same server (sticky sessions). Useful when server-side state exists (in-memory sessions, local caches). The trade-off: if that server goes down, all its “sticky” users lose their sessions. Consistent hashing minimizes this disruption.

​

Layer 4 vs Layer 7 Load Balancing

• Layer 4 (Transport Layer): Operates on TCP/UDP. Sees IP addresses and ports but not HTTP headers, URLs, or cookies. Extremely fast (near wire-speed) because it does not parse application data. AWS NLB operates at Layer 4. Use when: you need raw throughput, TLS passthrough, or are load balancing non-HTTP protocols (gRPC, database connections, custom TCP).
• Layer 7 (Application Layer): Operates on HTTP/HTTPS. Can route based on URL path (/api/* to backend, /static/* to CDN origin), headers (Accept-Language for regional routing), cookies (session affinity), or even request body content. AWS ALB, NGINX, and HAProxy operate at Layer 7. Use when: you need content-based routing, A/B testing, canary deployments, or WAF integration.

​

Technical Implementation (Node.js)

const cluster = require('cluster');
const numCPUs = require('os').cpus().length;
const express = require('express');

if (cluster.isMaster) {
    for (let i = 0; i < numCPUs; i++) cluster.fork();
    
    cluster.on('exit', (worker) => {
        console.log(`Worker ${worker.process.pid} died. Respawning...`);
        cluster.fork();
    });
} else {
    const app = express();
    app.get('/', (req, res) => res.send(`Handled by worker ${process.pid}`));
    app.listen(3000);
}

​

3. Caching & Streaming

​

Caching Patterns

1. Cache-Aside (Lazy Loading): App checks cache first; on a miss, reads from DB, then writes the result to cache. This is the most common pattern. The gotcha: cache stampede — when a popular key expires, hundreds of concurrent requests all miss the cache simultaneously and slam the database. Mitigation: use locking (only one request fetches from DB, others wait) or probabilistic early expiration (refresh the cache slightly before TTL expires).
2. Write-Through: App writes to cache and DB simultaneously (or the cache layer handles the DB write). Guarantees cache is always consistent with DB. The cost: every write has the latency of both the cache write and the DB write. Used when read-after-write consistency is critical, like user session data.
3. Write-Behind (Write-Back): App writes to cache immediately; the cache asynchronously flushes to DB later (typically in batches). Gives you the fastest write latency but introduces a durability risk — if the cache node crashes before flushing, you lose data. Used for: analytics counters, view counts, rate limiting counters — data where losing a few writes is acceptable. Facebook uses this pattern for “Like” counts.
4. Read-Through: Similar to cache-aside, but the cache itself is responsible for loading from the database on a miss (the application only talks to the cache, never directly to the DB). Simplifies application code but requires the cache layer to understand your data source.
5. Refresh-Ahead: The cache proactively refreshes entries before they expire, based on predicted access patterns. Reduces cache miss latency for hot keys but wastes resources if predictions are wrong.

​

Cache Invalidation

• TTL-based expiration: Simplest approach. Set a 60-second TTL and accept that data might be stale for up to 60 seconds. Works for most use cases. The art is choosing the right TTL — too short and you get excessive cache misses; too long and users see stale data.
• Event-driven invalidation: When data changes, publish an event (via Kafka, Redis Pub/Sub, or database triggers) that invalidates the corresponding cache key. More complex but gives you near-real-time consistency. This is what Facebook’s McSqueal does — it listens to MySQL’s binlog to invalidate Memcached keys.
• Version-based invalidation: Instead of invalidating, append a version number to the cache key (user:123:v7). When data changes, increment the version. Old keys naturally expire via TTL. Simple and avoids race conditions but wastes cache memory.

​

Real-time Communication

​

4. Behavioral & Decision-Making (Scenario-Based)

​

Scenario 1: Critical Deadline

​

Scenario 2: Security vs Feature Launch

​

Scenario 3: Monolith vs Microservices Migration

​

5. Technical Deep Dives (Sample Questions)

app.get('/healthz', (req, res) => {
  res.status(200).json({ status: 'alive', uptime: process.uptime() });
});

app.get('/readyz', async (req, res) => {
  const checks = {};
  let healthy = true;
  
  // Database check with timeout
  try {
    const start = Date.now();
    await Promise.race([
      db.query('SELECT 1'),
      new Promise((_, reject) => 
        setTimeout(() => reject(new Error('timeout')), 2000)
      )
    ]);
    checks.database = { status: 'ok', latency_ms: Date.now() - start };
  } catch (err) {
    checks.database = { status: 'error', message: err.message };
    healthy = false;
  }
  
  // Redis check
  try {
    const start = Date.now();
    await redis.ping();
    checks.redis = { status: 'ok', latency_ms: Date.now() - start };
  } catch (err) {
    checks.redis = { status: 'error', message: err.message };
    healthy = false;
  }
  
  // Memory check (alert if RSS > 80% of container limit)
  const memUsage = process.memoryUsage();
  const memLimitMB = parseInt(process.env.MEMORY_LIMIT_MB || '512');
  const rssMB = memUsage.rss / 1024 / 1024;
  checks.memory = { 
    rss_mb: Math.round(rssMB), 
    limit_mb: memLimitMB,
    status: rssMB < memLimitMB * 0.8 ? 'ok' : 'warning'
  };
  
  res.status(healthy ? 200 : 503).json({ 
    status: healthy ? 'ready' : 'degraded',
    checks,
    version: process.env.APP_VERSION || 'unknown'
  });
});

// Sliding window counter with Redis
async function isRateLimited(userId, limit, windowSec) {
  const now = Math.floor(Date.now() / 1000);
  const currentWindow = Math.floor(now / windowSec);
  const previousWindow = currentWindow - 1;
  const positionInWindow = (now % windowSec) / windowSec;
  
  const [currentCount, previousCount] = await redis.mget(
    `rate:${userId}:${currentWindow}`,
    `rate:${userId}:${previousWindow}`
  );
  
  const weightedCount = (parseInt(currentCount) || 0) + 
    (parseInt(previousCount) || 0) * (1 - positionInWindow);
  
  if (weightedCount >= limit) return true;
  
  await redis.multi()
    .incr(`rate:${userId}:${currentWindow}`)
    .expire(`rate:${userId}:${currentWindow}`, windowSec * 2)
    .exec();
  
  return false;
}

​

6. Preparation Checklist

• STAR Method: Practice Situation, Task, Action, Result for behavioral answers. Record yourself and listen for vague language (“we did” instead of “I did”, “improved performance” instead of “reduced p95 latency from 800ms to 120ms”).
• Trade-offs: Always mention pros and cons before picking an option. The phrase “It depends on…” followed by specific factors is what interviewers want to hear — not definitive statements without qualification.
• Coding: Be ready to explain Express middleware chains (the next() flow), Redis data structures beyond just GET/SET (sorted sets for leaderboards, HyperLogLog for cardinality estimation), and SQL indexing (B-tree vs hash indexes, composite index column ordering, partial indexes).
• Infrastructure: Understand Layer 4 vs Layer 7 load balancing, the difference between horizontal and vertical scaling, and why auto-scaling has a lag that matters.
• Numbers to know: 1ms for a Redis roundtrip, 5ms for a simple database query, 50ms for a cross-AZ network call, 150ms for a cross-continent roundtrip. Know the latency hierarchy and use it to justify design decisions.
• System design framework: Requirements (functional + non-functional) then API design then data model then high-level architecture then deep dive on the hardest part then scaling and trade-offs. Practice this flow until it is automatic.
• Ask clarifying questions: Before diving into an answer, ask 2-3 clarifying questions. “What is the expected QPS?”, “Do we need strong consistency or is eventual OK?”, “What is the read/write ratio?” This signals senior-level thinking.