Backend Development Architecture, Scalability and Distributed Systems Syllabus

Compare write-through vs write-back (write-behind) caching.

Write-through: writes go to cache and the datastore synchronously—consistent but higher write latency. Write-back: writes go to cache immediately and are flushed to the datastore asynchronously later—faster writes but risk of data loss if the cache fails before flush.

What is the read-through caching pattern?

The application always reads from the cache, and the cache itself is responsible for loading missing data from the backing store on a miss (the cache library/provider does the fetch, not the app).

Distinguish a cache hit, a cache miss, and cache eviction.

Hit: requested data is found in the cache. Miss: data is absent and must be fetched from the source. Eviction: removing entries (per a policy like LRU) to make room when the cache is full.

What is Redis and one feature that distinguishes it from Memcached?

Redis is an in-memory key-value data store. Unlike Memcached, it supports rich data structures (lists, sets, sorted sets, hashes, streams), persistence (RDB/AOF), replication, and pub/sub.

Give two differences between Redis and Memcached.

(1) Redis supports many data types and optional persistence; Memcached stores only strings/blobs in memory with no persistence. (2) Redis is largely single-threaded for commands with clustering/replication; Memcached is multithreaded and purely a simple volatile cache. Memcached can be simpler/faster for basic string caching.

What are RDB and AOF persistence in Redis?

RDB (Redis Database) takes point-in-time binary snapshots at intervals. AOF (Append-Only File) logs every write operation so the dataset can be reconstructed by replay, giving better durability at the cost of larger files.

What does TTL (time-to-live) mean for a cache entry?

A per-entry expiration duration after which the entry is considered stale and is removed or refreshed. TTL bounds staleness and automatically evicts old data without manual invalidation.

Name three common cache eviction policies.

LRU (Least Recently Used), LFU (Least Frequently Used), and FIFO (First-In-First-Out). Redis also offers random and TTL-based (volatile-ttl) variants.

What is a cache stampede (thundering herd) and one mitigation?

When a popular key expires and many concurrent requests simultaneously miss and hit the database to recompute it. Mitigations: request coalescing/locking (single-flight), early/probabilistic recomputation, or staggered/jittered TTLs.

Why is explicit cache invalidation hard, and what are the two main strategies?

Because the cache and source of truth can drift out of sync. Strategies: (1) TTL-based expiry (let entries auto-expire), and (2) active invalidation (delete/update the cache entry when the underlying data changes, e.g., write-through or event-driven purge).

Compare synchronous vs asynchronous messaging.

Synchronous: the caller blocks and waits for a response (request/response, e.g., HTTP), giving immediate results but tight temporal coupling. Asynchronous: the sender emits a message and continues without waiting; a consumer processes it later, giving loose coupling and resilience at the cost of eventual consistency.

What is a message broker and what does it provide?

Middleware that receives, stores, routes, and delivers messages between producers and consumers. It provides decoupling, buffering, delivery guarantees, and often persistence (e.g., RabbitMQ, Apache Kafka, ActiveMQ).

Compare a message queue with the publish/subscribe model.

Queue (point-to-point): each message is delivered to exactly one consumer among competing consumers. Pub/Sub: each message is broadcast to all subscribers of a topic, so many consumers each receive a copy.

What is event streaming and how does it differ from traditional queuing?

Event streaming (e.g., Kafka) stores an ordered, durable, replayable log of events that consumers read at their own offset; events are retained after consumption. Traditional queues typically delete a message once it is consumed/acknowledged.

In Kafka, define topic, partition, and offset.

A topic is a named stream of records. A topic is split into partitions for parallelism and ordering; ordering is guaranteed only within a partition. An offset is the monotonically increasing position of a record within a partition, tracked per consumer group.

What is a consumer group in Kafka and how does it affect parallelism?

A set of consumers sharing a group ID; Kafka assigns each partition to exactly one consumer in the group, so max parallelism equals the number of partitions. Different groups each get a full copy of the stream.

What are background jobs and workers?

Background jobs are tasks executed outside the request/response cycle (e.g., sending email, generating reports). Workers are long-running processes that pull jobs from a queue and execute them asynchronously, keeping user-facing requests fast.

Why offload work to a background job instead of doing it inline in a request?

To keep response latency low, avoid blocking the user on slow/expensive operations, absorb load spikes via the queue, and enable retries and independent scaling of the work.

Define idempotency in the context of message processing.

An operation is idempotent if performing it multiple times has the same effect as performing it once. This lets a system safely retry or re-deliver a message without causing duplicate side effects.

Compare the three message delivery guarantees.

At-most-once: message may be lost but never duplicated (no retries). At-least-once: message is never lost but may be delivered more than once (retries → duplicates). Exactly-once: each message effectively processed once—hardest to achieve, usually via idempotency plus deduplication/transactions.

What is an idempotency key and how is it used?

A unique client-supplied identifier attached to a request/message. The server records processed keys and, on a repeat with the same key, returns the original result instead of reprocessing—turning at-least-once delivery into effectively exactly-once.

What is a dead-letter queue (DLQ)?

A separate queue where messages are routed after repeatedly failing processing or exceeding a retry limit, so they can be inspected/handled later without blocking the main queue.

Compare horizontal scaling (scale-out) with vertical scaling (scale-up).

Vertical: add more resources (CPU, RAM) to a single machine—simple but bounded by hardware limits and a single point of failure. Horizontal: add more machines/nodes—nearly unbounded and fault-tolerant, but requires load balancing and handling distributed state.

Give one advantage and one limitation of vertical scaling.

Advantage: no application changes needed—just a bigger box, and no distributed-systems complexity. Limitation: hard ceiling (max hardware), higher marginal cost, and the single machine remains a single point of failure.

Name four common load-balancing algorithms.

Round Robin, Least Connections, IP/source Hash (sticky by client), and Weighted Round Robin (or Least Response Time). These distribute requests across backend servers by different criteria.

How does the Least Connections load-balancing strategy work, and when is it preferred?

It routes each new request to the backend server currently handling the fewest active connections. Preferred when requests have variable/long durations, since round robin can overload a server stuck with slow requests.

Contrast Layer 4 and Layer 7 load balancing.

Layer 4 balances on transport info (IP/TCP/UDP ports) without inspecting payload—fast and protocol-agnostic. Layer 7 inspects application data (HTTP headers, URLs, cookies), enabling content-based routing, SSL termination, and sticky sessions at higher processing cost.

What is a stateless service and why is it desirable for scaling?

A service that keeps no client session state between requests—each request contains all needed context. It lets any instance handle any request, so instances can be added/removed freely behind a load balancer without session affinity, enabling easy horizontal scaling and failover.

How do you keep services stateless when sessions are needed, and what is a session store?

Externalize session state into a shared session store—a fast, centralized datastore (e.g., Redis) holding session data keyed by a session ID. The service instances stay stateless and read/write session data from the store.

What is sticky session (session affinity) and its main drawback?

The load balancer routes a given client consistently to the same backend so in-memory session state persists there. Drawback: it undermines even load distribution and stateless failover—if that server dies, the session is lost.

Distinguish failover from redundancy.

Redundancy is having duplicate/backup components so no single failure causes outage. Failover is the automatic mechanism that switches traffic/workload to a healthy standby when a primary component fails—redundancy is the resource, failover is the switch.

Compare active-active and active-passive failover configurations.

Active-active: all nodes serve traffic simultaneously and share load; on failure survivors absorb the load (better utilization). Active-passive: a standby node stays idle/on-hold and takes over only when the active node fails (simpler, but wasted standby capacity and brief failover delay).