Goldman Sachs

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.

With REQUIRED, inner and outer share one physical transaction. When the inner proxy sees a runtime exception, it marks the shared transaction rollback-only. Catching the exception outside does not clear the mark, so the outer commit attempt becomes a rollback and Spring reports UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only.

Solutions: use REQUIRES_NEW (or NESTED with savepoints) for the part that may fail independently, or avoid calling a transactional bean that throws when you intend to recover.

Behaviour when a transaction already exists / does not:

• REQUIRED (default): join / create new.
• REQUIRES_NEW: suspend current and create new / create new.
• NESTED: savepoint within current / create new (like REQUIRED).
• SUPPORTS: join / run non-transactionally.
• MANDATORY: join / throw IllegalTransactionStateException.
• NOT_SUPPORTED: suspend and run non-transactionally / non-transactionally.
• NEVER: throw / non-transactionally.

Offsets are committed after processing; if a rebalance or crash happens between side effect and commit, another consumer reprocesses the message (at-least-once). The side effect is not idempotent.

• Make the charge idempotent: pass the event/payment ID as the payment provider's idempotency key and record it in a unique-constrained table in the same DB transaction.
• Commit offsets only after success; handle ConsumerRebalanceListener to finish/abandon in-flight work.
• Tune max.poll.interval.ms / max.poll.records so slow processing does not trigger a rebalance.
• Do not rely on Kafka transactions for non-Kafka side effects.

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