PayPal

Common causes on Java 21: pinning from blocking inside synchronized (JDBC drivers, legacy libs), blocking native calls, a fixed-size pool of connections or a semaphore throttling everything, and ThreadLocal heavy caching (millions of copies). Diagnose with JFR event jdk.VirtualThreadPinned and -Djdk.tracePinnedThreads=full. Fixes: use ReentrantLock, upgrade the library, or Java 24+.

HashMap keeps an array of buckets (Node<K,V>[] table). The key's hashCode() is spread, masked to an index, and the entry is stored in that bucket as a linked list (or a red-black tree when large). Lookup compares hash then equals.

• Index = (n - 1) & hash where n is a power of two.
• Spread function: h ^ (h >>> 16) mixes high bits into low bits.
• Default capacity 16, load factor 0.75.
• Allows one null key and many null values; not thread-safe.

No. Declarative transactions are applied by a proxy around a Spring bean. The proxy only intercepts calls arriving through it to methods it can override, so new-created objects, private, and final methods (CGLIB cannot override them) get no transaction and fail silently.

• Annotate public methods on beans; since Spring 6, protected and package-private methods are also supported with class-based (CGLIB) proxies.
• Check with TransactionSynchronizationManager.isActualTransactionActive() or by logging org.springframework.transaction at DEBUG.
• Put @Transactional on the service layer, not controllers or repository interfaces' callers' internals.

Self-invocation bypasses the proxy, so the REQUIRES_NEW annotation is never evaluated; saveAudit() runs inside the caller's transaction and rolls back with it.

Fix by moving it to a separate bean:

@Service
class AuditService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void save(AuditEvent e) { repo.save(e); }
}

Alternatives: self-injection, TransactionTemplate inside the method, or AspectJ mode.

By default Spring rolls back only on unchecked exceptions (RuntimeException and Error). A checked exception commits whatever was flushed. Declare rollbackFor = Exception.class (or specific types) to roll back on checked ones.

@Transactional(rollbackFor = IOException.class)
public void importFile(Path p) throws IOException { ... }

This rule mirrors EJB convention. noRollbackFor does the inverse.

JOIN FETCH loads the association in the same SQL join and initializes it on the returned entities, so the loop does no further queries.

@Query("select o from Order o join fetch o.customer where o.status = :s")
List<Order> findWithCustomer(OrderStatus s);

• Plain join fetch is an inner join; use left join fetch to keep parents with no children.
• Fetching a collection multiplies rows (Cartesian product); Hibernate 6 de-duplicates parent entities automatically, so distinct is no longer needed for that purpose (it only affects SQL if you want it).
• You cannot alias-filter a fetched collection reliably; filtering it makes the in-memory collection incomplete.

When a lazy association of one entity is touched, Hibernate initializes the same association for up to N other uninitialized entities in the persistence context using where id in (?, ?, ...). 101 queries become 1 + ceil(100/N).

• Set globally: spring.jpa.properties.hibernate.default_batch_fetch_size=32.
• It works for collections and lazy to-one proxies, and composes with pagination because the parent query keeps its LIMIT.
• Hibernate 6 may pad IN lists to powers of two for statement-cache reuse (in_clause_parameter_padding).

An operation is idempotent if repeating it has the same effect as doing it once. Networks time out and clients retry, so a "create payment" call must not charge twice. Use a client-supplied idempotency key enforced by a unique constraint.

CREATE TABLE payment (
  id bigserial PRIMARY KEY,
  idempotency_key text NOT NULL UNIQUE,
  amount numeric(12,2) NOT NULL,
  status text NOT NULL,
  response jsonb
);

INSERT INTO payment (idempotency_key, amount, status)
VALUES ('k-123', 50.00, 'PENDING')
ON CONFLICT (idempotency_key) DO NOTHING;   -- 0 rows => replay: return stored response

• Insert the key and perform the side effect in the same transaction where possible; for external calls (PSP) pass the key downstream too.
• Store the response so a retry returns the same result; reject same key with a different payload (422).
• Expire keys after a window (e.g. 24 h).
• MySQL equivalent: INSERT ... ON DUPLICATE KEY UPDATE or INSERT IGNORE.
• PUT and DELETE are idempotent by definition; POST is not and needs the key.

A saga is a sequence of local transactions, each with a compensating action, replacing a distributed ACID transaction. Choreography uses events between services; orchestration uses a central coordinator.

Order -> Payment -> Inventory -> Shipping
fail at Inventory: refund Payment (compensate), cancel Order

• Sagas give ACD (no isolation): intermediate states are visible; use semantic locks, pending states, commutative updates.
• Compensations must be idempotent and retryable; steps use outbox for reliable messaging.

2PC gives atomic commit across databases but is a blocking protocol: participants hold locks from PREPARE until the coordinator decides, so a coordinator crash or slow participant stalls everyone. In a service-per-database architecture that couples availability and latency of all services and many stores (Kafka, REST calls, most NoSQL) do not support it, so sagas with compensations are used instead.

• Phase 1: coordinator asks all participants to prepare (durably log, hold locks); phase 2: commit if all voted yes, otherwise abort.
• Failure window: participant prepared, coordinator dies, participant is "in doubt" and cannot unilaterally release locks.
• Saga: sequence of local transactions, each publishing an event; failures trigger compensating transactions in reverse. Trade-off: no isolation (intermediate states are visible), so design semantic locks or pending states.
• 2PC (XA) still fits a small, trusted set of resources inside one data centre, for example a database plus a JMS broker in an application server, where strong atomicity beats availability.

Combine a hash map for lookup with a doubly linked list for recency order; both get and put are O(1). In Java, LinkedHashMap with access order does this in a few lines.

class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int capacity;
    LRUCache(int capacity) { super(16, 0.75f, true); this.capacity = capacity; }
    @Override protected boolean removeEldestEntry(Map.Entry<K, V> e) { return size() > capacity; }
}

• Interviewers often want the manual version: Map<K, Node> plus head/tail sentinels; get moves the node to head, put evicts tail when full.
• Not thread-safe; wrap with Collections.synchronizedMap or a lock (even get mutates order).

Accept payment requests with an idempotency key, orchestrate calls to a PSP through a state machine, and record every money movement in an append-only double-entry ledger with periodic reconciliation.

• Requirements: charge, refund, multiple payment methods, exactly-once effect, auditability, PCI compliance, high consistency.
• Estimates: 1M payments/day (~12/s, peak 100/s); low QPS, extreme correctness requirement.
• API: POST /v1/payments {orderId, amount, currency, method} with Idempotency-Key header; GET /payments/{id}; webhooks from PSP.
• Data model: payments(id, order, amount, state, idem_key UNIQUE), ledger_entries(id, txn_id, account, debit/credit, amount); amounts in minor units.

Checkout -> Payment API -> Payment DB (state) -> PSP Adapter -> PSP (Stripe/Adyen)
PSP webhook -> Webhook Handler (verify signature) -> update state -> Ledger -> Kafka events
Reconciliation Job: PSP settlement files vs ledger

• Idempotency: unique key stored with the request hash and response; replays return the stored result.
• State machine: CREATED -> PENDING -> SUCCEEDED/FAILED; timeouts are unknown outcomes, so query the PSP status before retrying and never blindly re-charge.
• Use the outbox pattern to publish events atomically with DB updates.
• Trade-offs: synchronous confirmation vs async webhook; never store raw card data (tokenize via PSP).
• Failure modes: PSP timeout (unknown state, poll and reconcile), duplicate webhooks (idempotent handler), ledger imbalance caught by reconciliation.