🌍 Backend Development · flashcards

Backend Development Architecture, Scalability and Distributed Systems Flashcards

52 question-and-answer cards covering Architecture, Scalability and Distributed Systems as it is examined in Backend Development. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.

52Cards in deck
24Free preview
28Syllabus topics
~238Chars per answer
FreePrice

24 sample cards from the Architecture, Scalability and Distributed Systems deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

  1. 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.

  2. 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).

  3. 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.

  4. 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).

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. 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.

  15. 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.

  16. 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.

  17. 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.

  18. 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.

  19. 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.

  20. 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.

  21. 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.

  22. 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.

  23. 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.

  24. 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).

What this deck covers

The Architecture, Scalability and Distributed Systems deck follows the Backend Development Architecture, Scalability and Distributed Systems syllabus — 6 chapters and 28 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 8.7 cards per chapter.

Answers are written to be recallable, not just readable — averaging about 238 characters, which is long enough to carry the reasoning and short enough to say out loud.

A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.

Architecture, Scalability and Distributed Systems flashcards FAQ

How many Architecture, Scalability and Distributed Systems flashcards are in this Backend Development deck?

52 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.

Are these Backend Development flashcards free?

Yes. The preview here is free to read with no signup, and the full 52-card deck is free inside the Examius app.

What do the Architecture, Scalability and Distributed Systems cards cover?

They follow the Backend Development Architecture, Scalability and Distributed Systems syllabus — 6 chapters and 28 topics — so the questions track what is actually examinable.

How should I use these flashcards?

Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.