پرسش‌وپاسخ سریع: معماری، همزمانی و طراحی سیستمRapid-Fire Q&A: Architecture, Concurrency & System Design

Intuition: The JMM doesn't build a full timeline; it just draws reliable edges that say "whatever was written on this side of the edge is definitely visible on the other side."

Answer: The JMM defines a partial order called happens-before over memory operations. If action A happens-before B, then A's writes are visible to B and ordered before it. Without a happens-before edge, one thread's writes may be reordered, cached, or invisible to another thread — indefinitely. So the JMM is not about "when things run"; it is about which writes a read is allowed to observe.

Key edges to memorize:

• program order within a thread;
• unlock→lock on the same monitor;
• volatile write→subsequent volatile read of the same field;
• Thread.start()→the thread's first action;
• a thread's last action→another thread's join();
• and final field freeze at the end of the constructor.

Intuition: volatile is a loudspeaker on one variable: whatever you say, everyone hears immediately — but it can't stop two people from talking at once. synchronized is a room with one key: only one person enters, does the work across several fields, and publishes everything on the way out.

Answer: volatile gives visibility and ordering for a single variable but no atomicity for compound actions — x++ is really read-modify-write and stays racy. synchronized gives mutual exclusion + visibility for everything the lock guards, and establishes happens-before via unlock/lock.

Choice rule: use volatile for a flag or a safely-published reference; use synchronized/locks when you need to hold an invariant across multiple fields together.

Code:

class Holder {
    static boolean ready = false;   // NOT volatile
    static int value = 0;
    static void writer() { value = 42; ready = true; }
    static void reader() { while (!ready) {} System.out.println(value); }
}
// Thread A runs reader(), Thread B runs writer()

Intuition: Without a happens-before edge, the reader thread is allowed to read ready "once and for all" into its notepad and never look at the whiteboard again.

Answer: It may print 42, may print 0, or may never terminate. Because ready is not volatile, there is no happens-before edge between the writer and reader. The JIT is legally allowed to hoist !ready out of the loop (read once into a register) → infinite loop. Even if it does exit, value may still be seen as 0, because the write to value can be reordered relative to ready and there is no visibility guarantee.

Making ready volatile fixes both: the volatile write publishes value too (piggyback ordering), and the volatile read is re-fetched each iteration.

Intuition: Constructing an object is two steps: fill the memory (constructor), then hand its address to the variable. If those two steps are seen out of order, another thread sees a non-null address backed by a half-built object.

Answer: The object reference could be published before the constructor finished, so another thread saw a non-null but partially-initialized object. The fix is volatile on the field: the volatile write of the reference cannot be reordered before the constructor's writes, and the volatile read establishes happens-before.

class Lazy {
    private static volatile Lazy instance;   // volatile is mandatory
    static Lazy get() {
        Lazy r = instance;                   // read volatile once
        if (r == null) {
            synchronized (Lazy.class) {
                r = instance;
                if (r == null) instance = r = new Lazy();
            }
        }
        return r;
    }
}

Senior note: prefer the initialization-on-demand holder idiom — a static nested class — where the classloader gives you lazy, thread-safe init for free with no volatile at all.

Intuition: Deadlock is like an intersection where four cars have all entered at once and each is waiting for the one on its right to move first. Remove just one of the four conditions and the knot unties.

Answer: The four conditions are: mutual exclusion, hold-and-wait, no-preemption, and circular wait. In practice you break circular wait by imposing a global lock ordering — always acquire locks in a canonical order (e.g. by System.identityHashCode or a business key). Alternatively break hold-and-wait with tryLock + backoff, or no-preemption with timeouts.

Broken code:

void transfer(Account from, Account to, long amount) {
    synchronized (from) {
        synchronized (to) { from.debit(amount); to.credit(amount); }
    }
}

Intuition: If one thread calls transfer(A,B) and another concurrently calls transfer(B,A), each grabs one lock and waits forever for the other — pure circular wait.

Answer: Impose a global order by sorting locks on a stable id, so both calls always take the same order:

void transfer(Account from, Account to, long amount) {
    Account first  = from.id() < to.id() ? from : to;
    Account second = from.id() < to.id() ? to   : from;
    synchronized (first) {
        synchronized (second) { from.debit(amount); to.credit(amount); }
    }
}

If ids can be equal (same account), guard against self-transfer or use a tie-breaker lock.

Intuition: Deadlock is everyone standing still and dead. Livelock is two people in a corridor both stepping aside the same way, over and over — active, but nobody gets through. Starvation is one person stuck at the door because others always jump in first.

Answer: Deadlock: threads blocked forever, no progress, no CPU burn. Livelock: threads are active and keep changing state in response to each other but make no progress. Starvation: a thread makes no progress because others monopolize a resource (unfair locks, priority inversion). Fairness policies and randomized backoff address livelock and starvation.

Intuition: See above — the chefs are carrier threads, the customers are virtual threads.

Answer: Virtual threads (stable since Java 21, JEP 444) are JDK-managed lightweight threads multiplexed M:N onto a small pool of OS carrier threads. When a virtual thread blocks on I/O, it unmounts from its carrier, freeing the OS thread to run another virtual thread. This makes the simple thread-per-request blocking style scale to millions of concurrent tasks.

They help when work is I/O-bound and blocking (DB calls, HTTP fan-out). They do not speed up CPU-bound work — you still have only N cores; a fixed-size platform-thread pool is right there. And never pool virtual threads; create one per task.

Intuition: Pinning is when the chef won't step away; even when the order only needs to sit in the oven, he stays glued to it and the whole queue stalls.

Answer: Pinning is when a virtual thread cannot unmount and holds its carrier hostage during a blocking operation. In Java 21–23, entering a synchronized block/method pinned the virtual thread (the monitor tracked the carrier, not the virtual thread), so long I/O inside synchronized starved the carrier pool. The Java-21-era advice was: replace hot synchronized guarding I/O with ReentrantLock.

Java 24 (JEP 491) rewrote the monitor implementation to be virtual-thread-aware, so synchronized no longer pins in virtually all cases, and -Djdk.tracePinnedThreads was removed. Remaining pinning sources: executing native code (JNI) or foreign functions. Senior takeaway: know your target JDK — the "avoid synchronized" rule is a Java-21/22/23 rule, not a permanent one.

Intuition: ThreadLocal is like sticking a sticky-note on the chef himself, not on the order. If chefs get recycled (a pool), the previous order's note lingers on the next order; and with millions of threads, millions of notes devour memory.

Answer: ThreadLocal leaks when used with pooled threads (the value survives across unrelated tasks) and adds per-thread memory that explodes with millions of virtual threads. Loom introduces scoped values (ScopedValue, finalized around Java 25) — immutable, bounded to a dynamic scope, and cheap to inherit into structured-concurrency child tasks. Prefer them for request-scoped context (tenant id, principal).

Intuition: CompletableFuture is like dispatching several couriers with no supervisor; if one gets lost, the others carry on oblivious. Structured concurrency adds a supervisor who, if one courier fails, recalls the rest and gives you one clear report.

Answer: CompletableFuture composes async callbacks but loses the parent-child relationship: a failure in one branch doesn't automatically cancel siblings, and errors surface as tangled exceptions. Structured concurrency (StructuredTaskScope, preview through Java 21–24) treats a group of subtasks as a unit: if one fails, the scope cancels the rest and propagates one clear error; the scope cannot leak threads because it joins before returning. It restores the call-stack discipline that async broke.

Intuition: Each principle neutralizes a "bad smell" in code; know the smell and you recall the principle without memorizing.

Answer:

• SRP — one reason to change; smell: a class edited by three different teams.
• OCP — open for extension, closed for modification; smell: adding a case means editing a giant switch.
• LSP — subtypes must be substitutable; smell: if (obj instanceof X) before calling a method, or a subclass throwing UnsupportedOperationException.
• ISP — many small interfaces beat one fat one; smell: implementers stubbing methods they don't need.
• DIP — depend on abstractions, not concretions; smell: new of a concrete service inside business logic.

Intuition: In math a square is a rectangle, but in code this inheritance is a trap because their behavioral contracts differ.

Answer: The classic: Square extends Rectangle. Rectangle has independent setWidth/setHeight; a Square must keep them equal, so overriding setWidth to also set height breaks any client that assumes setWidth(5); setHeight(4) yields area 20. The subtype strengthens a precondition / weakens a postcondition — the contract, not the code, is violated. Fix: model them as separate types or make shapes immutable.

Intuition: All three "vary behavior," but with three different levers: injection, inheritance, and internal state change.

Answer: Strategy injects an interchangeable algorithm via composition — runtime swap. Template Method fixes the skeleton in a base class and lets subclasses fill steps via inheritance — compile-time. State is Strategy where the object swaps its own behavior as internal state changes and the states know how to transition. Generally prefer Strategy over Template Method — composition over inheritance.

Intuition: Singleton is fine when "only one instance" is a genuine domain fact; it's bad when it becomes a hidden global variable everyone reaches for.

Answer: When it becomes a global mutable variable: it hides dependencies, defeats testability (you can't substitute it), creates hidden coupling, and is a concurrency hazard on lazy init. In a DI world you want a single instance managed by the container (scope = singleton) injected explicitly — same lifetime, none of the global-state pathology.

Intuition: All four wrap something, but with different intent: convert, simplify, control, augment.

Answer:

• Adapter: converts one interface to another the client expects (integration).
• Facade: a simplified entry point over a complex subsystem (reduces surface).
• Proxy: same interface, controls access (lazy load, security, remote, caching); Spring AOP uses dynamic proxies.
• Decorator: same interface, adds behavior by stacking wrappers (e.g. BufferedInputStream).

Key discriminator: Adapter changes the interface, Facade simplifies it, Proxy and Decorator keep it — but Proxy controls, Decorator augments.

Intuition: See above; and think of an Aggregate as a "case file" you may only open through its cover.

Answer: An Entity has identity and a lifecycle (equality by id). A Value Object is immutable and compared by value (Money, Address), with no identity. An Aggregate is a consistency boundary: a cluster of entities/VOs with one aggregate root that is the only external entry point; invariants inside the aggregate are enforced transactionally. Rule of thumb: one transaction should modify one aggregate; cross-aggregate consistency is eventual — via domain events.

Intuition: The word "Customer" in Sales, in Billing, and in Support is not the same thing; if you cram them all into one definition, you build a jack-of-all-trades mush that satisfies nobody.

Answer: A bounded context is a boundary within which a model and its ubiquitous language are consistent. Forcing one shared model across all units creates a coupled mess. Bounded contexts map naturally onto microservice boundaries and team ownership. The relationships between contexts (partnership, customer-supplier, conformist, anti-corruption layer) are your integration contract.

Intuition: Like an embassy translator: whatever comes from the foreign side is translated into your own language so their vocabulary and concepts never enter your house directly.

Answer: A translation layer that isolates your model from an external/legacy model, so their concepts and vocabulary don't leak into your domain. It converts at the boundary (their DTO → your value objects), protecting your ubiquitous language and letting the upstream system change without rippling inward.

Intuition: See above; "partition" is that dropped line.

Answer: Under a network partition (P), a distributed system must choose between consistency (C, linearizability) and availability (A, every request gets a non-error response). The common misreading: "pick 2 of 3." Partitions are not optional — networks fail — so you are really choosing CP or AP during a partition. When there is no partition, you can have both C and A. PACELC extends this: Else (no partition), you trade Latency vs Consistency. That is the more useful lens for daily design.

Answer: CP: a system built on consensus (etcd, ZooKeeper, or a single-leader RDBMS with synchronous replication) — it refuses writes on the minority side of a partition to preserve consistency. AP: Cassandra/DynamoDB with quorum tuned for availability, or DNS — they keep serving and reconcile later (last-write-wins, vector clocks, CRDTs). Note you can tune per-operation (Cassandra consistency levels).

Intuition: On a network you can never tell "my request was lost" from "its response was lost" — so you must resend. If the operation isn't idempotent, that "resend" means charging twice.

Answer: An operation is idempotent if applying it N times has the same effect as applying it once. Because on a network you cannot tell "request lost" from "response lost," clients retry, and retries cause duplicates. Idempotency is what makes retries safe. Implement with an idempotency key: the client sends a unique key; the server records (key → result) and on a repeat returns the stored result instead of re-executing.

-- Idempotent payment insert: the unique key makes the duplicate a no-op
INSERT INTO payments (idempotency_key, order_id, amount, status)
VALUES ('c1f...-uuid', 42, 1999, 'CAPTURED')
ON CONFLICT (idempotency_key) DO NOTHING;   -- Postgres: second attempt inserts 0 rows

Intuition: Two separate actions in two separate systems with no shared transaction is like saying "I do" at the registry and then driving to the bank to sign — anything can happen in between and leave you half-done.

Answer: Because they are two separate systems with no shared transaction — a dual-write problem. If you commit the DB then the broker is down, the event is lost; if you publish then the DB rolls back, you emitted a phantom event. There is no atomicity across the two. The fix is the Transactional Outbox: within the same DB transaction that changes state, insert the event into an outbox table. A separate relay (polling or CDC via Debezium reading the WAL) publishes committed outbox rows to Kafka. Now the state change and the "intent to publish" are atomic; delivery becomes at-least-once, so consumers must be idempotent.

Intuition: Choreography is like a group dance with no director — each dancer does the next move on seeing their neighbor's; beautiful, but hard to follow the whole flow. Orchestration has a director telling each person when to do what.

Answer: A saga manages a distributed transaction as a sequence of local transactions, each with a compensating action to undo it (there is no distributed rollback). Choreography: services react to each other's events, no central coordinator — decoupled but hard to follow and reason about (emergent flow). Orchestration: a central saga orchestrator tells each service what to do and drives compensations — explicit, observable, easier to change, at the cost of a coordinator. Sagas give you eventual consistency and atomicity via compensation, never isolation — you can observe intermediate states, so design for semantic locks or pending states.

Intuition: 2PC is like several deal parties all holding their pens, waiting for one person's signal to sign at the same instant; if that person vanishes, everyone freezes with pen raised.

Answer: 2PC (two-phase commit) gives true ACID atomicity across services via a coordinator (prepare, then commit/abort). It is blocking: if the coordinator dies after prepare, participants hold locks indefinitely, killing availability and scalability, and it couples service lifecycles. Sagas trade isolation for availability and are the pragmatic choice at scale.

Intuition: "Exactly-once delivery" over a network is largely a myth; but "exactly-once effect" is achievable — the message may arrive twice, yet its effect is recorded only once.

Answer: You don't get exactly-once delivery — you get exactly-once processing effect by making consumers idempotent: dedupe on the event id / idempotency key, or use idempotent upserts, or Kafka's transactional producer + read_committed for the internal Kafka-to-Kafka hop. Effect-level exactly-once + at-least-once delivery is the real-world combination.

Intuition: These are like a building's safety system: timeout = the alarm, circuit breaker = the electrical fuse, bulkhead = fire doors confining the fire to one section, retry = a cautious second attempt, rate limiter = the elevator's max occupancy.

Answer:

• Timeout: never wait forever; every remote call needs one. It is the foundation — without it, everything else fails.
• Retry: re-attempt transient failures, with exponential backoff + jitter to avoid synchronized retry storms; only retry idempotent ops.
• Circuit breaker: after a failure threshold, open the circuit and fail fast for a cooldown, then half-open to probe recovery. Stops you from hammering a dying dependency and cascading.
• Bulkhead: isolate resources (separate thread pools / connection pools per dependency) so one slow dependency can't exhaust all threads and sink the whole service.
• Rate limiter: cap request rate to protect a resource.

[GOTCHA] interaction: naive retry inside a circuit breaker multiplies load; and retries at every layer of a call chain cause retry amplification (3 layers × 3 retries = 27×). Budget retries end-to-end and prefer retrying at one layer.

Intuition: Like an assembly line where the last worker signals the first "slow down, my hands are full"; without that signal, parts pile up on the floor until the line collapses.

Answer: Backpressure is a consumer signaling a fast producer to slow down so queues don't grow unbounded (→ OOM, latency collapse). Mechanisms: bounded queues that block/reject when full, Reactive Streams' request(n) demand, TCP flow control, or Kafka consumer lag as a natural buffer. The anti-pattern is an unbounded in-memory queue that hides the overload until the process dies.

Intuition: Because Kafka is at-least-once by default, "handle duplicates" is a design requirement, not a rare edge case.

Answer: Track processed offsets/event-ids transactionally with the side effect: process the message and record its id in the same DB transaction, so a redelivery after a crash is detected and skipped. Alternatively design the write itself to be idempotent (upsert by business key).

Intuition: Three different layers: "where do I find it?", "where's the front door to the whole system?", and "what are the rules for traffic between the houses?"

Answer: Service discovery (Eureka, Consul, K8s DNS): find healthy instances dynamically. API gateway: single north-south entry — auth, routing, rate limiting, aggregation. Service mesh (Istio/Linkerd via sidecars): east-west concerns — mTLS, retries, timeouts, traffic shifting, observability — moved out of app code into the platform. Mesh is infrastructure-level resilience so every service gets it uniformly without a library.

Intuition: Three levels of data "freshness": always see the latest truth, eventually get there, or at least see the cause before the effect.

Answer: Strong (linearizable): every read sees the latest write; needed for money, inventory decrements, uniqueness. Eventual: replicas converge given no new writes; fine for feeds, counts, caches, "likes." Causal: preserves cause→effect ordering (you see a reply only after the message it answers) — a sweet spot for collaborative and social apps, cheaper than strong.

Intuition: Replication is several identical photocopies of one ledger (for more reads and backup); sharding is tearing the ledger into smaller ledgers, each holding different data (for more writes and storage).

Answer: Replication copies the same data (read scaling + HA); sharding partitions different data across nodes (write + storage scaling). The hard parts of sharding: choosing a shard key that spreads load without hotspots, cross-shard queries/joins (avoid or scatter-gather), cross-shard transactions (avoid — you're back to sagas/2PC), and resharding as you grow (consistent hashing minimizes data movement).

Intuition: Imagine a hot key (say a celebrity's page) expiring at one exact instant; in that same instant thousands of requests all see the cache is empty and stampede the DB together — like a stadium gate suddenly opening.

Answer: Even with write-through, a cache stampede happens when a hot key expires and thousands of requests miss simultaneously and all hit the DB. Mitigations: request coalescing / single-flight (only one loader per key), probabilistic early expiration, stale-while-revalidate, or jittered TTLs. Separately, the dual-write between cache and DB is inconsistent under failure — prefer cache-aside with invalidation and accept a small staleness window, or use CDC to invalidate. There is no perfectly consistent cache without giving up availability or latency.

Intuition: This system is heavily read-heavy (roughly 100 reads per write), so all the craft is in making the read path fast.

Answer: Clarify: read-heavy (100:1), custom aliases?, analytics?, TTL? Key generation: base62 of a global counter (needs a distributed id — Snowflake or a ranged ticket server), not a hash (collisions, length). API: POST /urls → short code, GET /{code} → 301/302 redirect. Storage: KV store (code → longUrl), heavily cached (the read path is a cache hit + redirect). Scale: CDN + Redis in front of the DB; the write path is tiny. Discuss 301 (cached, loses analytics) vs 302 (every hit reaches you).

Intuition: Picture a "token bucket" filled at a steady rate; each request spends one token, and if the bucket is empty it's rejected — this allows short bursts yet controls the average.

Answer: Algorithms: token bucket (allows bursts up to bucket size, refills at rate) — the usual choice; sliding window log (accurate, memory heavy); sliding window counter (approximation, cheap). Distributed: store counters in Redis with atomic Lua scripts to avoid races; key by user:route. Discuss where it runs (gateway/mesh), fail-open vs fail-closed on Redis outage, and clock skew.

Intuition: Two ends of a spectrum: either precompute everyone's feed at write time (fast reads, but a disaster for a multimillion-follower celebrity), or assemble the feed at read time (cheap writes, slow reads).

Answer: The core trade-off is fan-out on write (push) vs fan-out on read (pull). Push precomputes each follower's feed on post (fast reads, expensive for celebrities with millions of followers — the "hot key / thundering herd" problem). Pull assembles the feed at read time (cheap writes, slow reads). Real systems use a hybrid: push for normal users, pull for celebrity accounts, merged at read. Add a message queue for async fan-out and idempotent delivery.

Intuition: You want each machine to mint a unique id without asking anyone; the trick is to build each id from pieces that never collide: time + which machine + a small counter.

Answer: Requirements: unique, roughly time-sortable, high throughput, no coordination on the hot path. Snowflake: 64-bit = timestamp | machine-id | per-ms sequence. Handles millions/sec, k-sortable, no central bottleneck. Pitfalls: clock skew / NTP going backwards (must refuse or wait), machine-id assignment, and the 2038-ish epoch/bit-budget. Alternatives: UUIDv7 (time-ordered, no coordination) or DB ticket servers.

STAR tip: Situation — the constraint (deadline, scale target, unknown load). Task — the decision you owned. Action — the options you weighed, the trade-off matrix (e.g. "we chose eventual consistency via outbox over 2PC because availability mattered more than isolation for orders"), and how you de-risked (spike, load test, feature flag). Result — a metric (p99 latency, cost, incident reduction) and what you'd revisit. Seniors are scored on how they reason about trade-offs, not on the tech chosen.

STAR tip: Situation — impact and blast radius. Task — your role (IC or coordinator). Action — how you stopped the bleeding first (rollback/feature-flag/scale), then diagnosed root cause; emphasize communication and the blameless post-mortem. Result — MTTR, the durable fix (added alert, backpressure, idempotency), and the systemic change so it can't recur. Never blame a person or vendor.

STAR tip: Show disagree-and-commit. Action — you made your case with data/prototype, listened to their constraints, and either changed your mind (intellectual honesty) or committed to their decision and made it succeed. Result — outcome plus preserved relationship. They are testing maturity, not that you "won."

Answer (decision framework): Default to a modular monolith unless you have a concrete forcing function: independent scaling of components, independent deploy cadence across teams, strong team/ownership boundaries (Conway's law), or polyglot needs. Microservices buy organizational scalability and pay in operational complexity (distributed transactions, observability, network failure, data duplication). Premature microservices on a small team is the most expensive mistake; extract services along bounded contexts once the seams are proven. STAR tip if asked for a story: quantify the team size and deploy pain that justified (or didn't justify) the split.

Answer: Incrementally and reversibly. Strangler fig to migrate off a legacy system route-by-route; expand-contract (parallel change) for schema and API — add the new field/endpoint, dual-write/dual-read, migrate readers, then remove the old — never a big-bang cutover. Guard everything behind feature flags, ship behind a canary, and keep a rollback path at each step. Measure at each gate.