In a Hurry

Common Patterns Overview

Patterns are reusable responses to recurring constraints.

A AceYourInterviews editorial · 9 min study

What, why, when and how

What is it?

Patterns are reusable mechanisms for recurring constraints such as contention, slow tasks, expensive reads or bursty writes.

Why is it needed?

The pattern must repair a visible limitation while preserving the product contract.

When should I use it?

Use one after you can reproduce the failure or measure the bottleneck in a complete baseline.

When should I choose something else?

Do not select it from the product name alone. Queues, locks and caches solve different boundaries.

How do I use it?

Write trigger, promise, owner, mechanism, limit and recovery; compare a simpler alternative under the same workload.

Can you show a concrete example?

An export burst at 1,000 jobs/s with 600/s completions adds 12,000 jobs in 30 seconds. A queue needs a bound and a drain policy; it does not raise completion capacity.

Burst arrivals 1,000/s; completions 600/s; 30 seconds adds 12,000 jobs; Later arrivals 100/s: spare 500/s drains in 24 s — Common Patterns Overview: one concrete example

Follow the detailed diagrams below to trace the additional state changes and failure cases behind these answers.

Outcome: select one of the seven common patterns from a broken baseline, then explain its mechanism, cost and recovery boundary.

A pattern is useful when it repairs a specific limitation. “This service is large” is too vague. “One worker can continue publishing after its lease expires” identifies an ownership failure. Several patterns can appear in the same product, but each must earn its operational cost.

Begin with a failure you can reproduce

For a ticket service, two buyers may both read that a seat is free. The missing mechanism is an authoritative atomic ownership transition. A queue may limit how many buyers reach that transition, but transporting requests is not itself the ownership rule. For an export, the request may outlive its connection. The missing mechanism is durable job state and discoverable completion. A lock on the export API does not supply that lifecycle.

Use a short decision record: trigger, user promise, authoritative state, mechanism, limit, failure and repair. This turns a pattern name into an argument the interviewer can test.

Choose among the seven patterns

Pattern	Concrete trigger	How it changes the baseline	Cost or wrong-fit case
Real-time Updates	A connected viewer needs changes within a declared delay	Poll or push changes, give them identities, resume or refresh after disconnect	Persistent connections and replay state may be excessive for rare updates
Dealing with Contention	Concurrent writers can violate one rule	Enforce a condition, transaction or serialization at the owner	A global lock unnecessarily couples independent resources; leases need resource-side fencing
Multi-step Processes	Several independent effects can partially succeed	Persist progress, retry safe steps, reconcile uncertainty and compensate under policy	Not needed when one local transaction covers the operation; compensation is not universal rollback
Scaling Reads	Measured repeated or expensive read work saturates the owner	Reduce fetched work, index, cache, replicate or project under a freshness contract	Extra copies complicate deletion, permissions and recovery
Scaling Writes	Bursts or sustained mutations exceed a measured budget	Batch, partition, buffer and bound admission	A queue postpones overload if the sink never catches up
Handling Large Blobs	Large bytes exhaust API memory, duration or bandwidth	Separate constrained byte transfer from small control/manifest operations	Small transactional values may be simpler in the database
Managing Long Running Tasks	Work exceeds request lifetime or needs resumable ownership	Return a durable job, lease bounded attempts, checkpoint and publish results safely	Fast predictable work may be simpler synchronously; cancellation cannot undo every completed effect

Quantify the trigger before changing the system

Assume an export service accepts 1,000 jobs/s for a 30-second burst and completes 600 jobs/s. Backlog grows by 400/s, accumulating 12,000 jobs during the burst. If arrivals then fall to 100/s, spare completion capacity is 500/s and that backlog needs at least 24 seconds to drain, excluding retries and variability. If arrivals stay at 1,000/s, there is no finite drain time at the stated capacity.

This arithmetic can justify a durable buffer and an admission limit. It cannot prove the completion deadline, worker memory or origin capacity. If one job holds 200 MB in memory, ten such jobs already imply about 2 GB before process overhead. Measure size classes and downstream budgets before multiplying worker count.

Three workload failures require different remedies: exclusive seat ownership, a request that outlives its connection, and a repeated expensive read. — Compare the failed baseline: worked example

Compose patterns by declaring each boundary

For a notification campaign, a durable workflow may own campaign progress. A queue buffers per-recipient work. A shared budget bounds provider requests. An attempt record preserves uncertain outcomes. A read projection supplies dashboard progress under declared lag. These responsibilities cooperate but are not interchangeable.

Boundary	Rule to enforce	What the neighboring pattern cannot supply
Campaign accepted	Intent and publication obligation are durable	An in-memory queue does not establish this commit
Delivery authorized	The applicable current preference policy permits submission	A campaign audience snapshot is not necessarily current consent
Provider called	Preserve the logical delivery identity and supported duplicate-prevention contract	Queue redelivery alone cannot prevent an external duplicate
Dashboard read	State what the visible count and lag mean	A cached total cannot establish provider delivery

Keep completed, failed, suppressed and unresolved outcomes distinct. The exact state names follow the product; do not force every domain into an identical state machine. The page Notification System applies these boundaries to a full problem.

A stale worker makes the failure visible

Worker A owns job j7 at epoch 9, then pauses. Its lease expires and worker B obtains epoch 10. When A resumes, a lease in the coordinator does not physically stop it. The destination that publishes the result must reject A's older epoch or otherwise enforce current ownership. If that destination is an external provider with no fencing interface, preserve the provider operation identity and explain the remaining uncertainty. Do not imply that database fencing controls arbitrary provider side effects.

This example joins long-running tasks, contention and multi-step effects. The useful question is which invariant each protects, and where protection ends.

Compare an alternative on the same requirement

For a short export that reliably finishes within a request deadline and does not need durable retry, synchronous execution can be adequate. For variable multi-minute exports, asynchronous job state usually gives a more honest contract. Compare user waiting time, accepted-work durability, status visibility and operational overhead. A preference for a familiar queue is not the deciding criterion.

Likewise, polling may satisfy a ten-second progress-update target with less connection machinery than a bidirectional socket. Choose a socket when bidirectional latency and interaction require it, then still solve reconnect, authorization and slow-consumer buffering.

Prediction and transfer exercises

Question: A queue holds 24,000 jobs while arrivals exceed completion by 400/s. How long until this finite buffer is exhausted if nothing changes?

Show answer and explanation

Answer: At most 60 seconds under those steady assumptions. Define when requests are rejected, deferred or admitted under a weaker deadline. Queue length and oldest age reveal different aspects of overload.

Question: A ticket hold and a scheduled job both expire. Can they use the same expiry policy?