Freshworks

The executor tries three things in a fixed order: start a core thread, then enqueue, and only when the queue refuses the task start a non-core thread up to maximumPoolSize; if that also fails the RejectedExecutionHandler runs. With an unbounded queue offer() never refuses, so the pool is stuck at corePoolSize and maximumPoolSize is dead configuration.

1. workers < corePoolSize: spawn a worker for this task, even if other core threads are idle.
2. Otherwise workQueue.offer(task); success means an idle worker will take() it later.
3. Queue full and workers < maximumPoolSize: spawn a non-core worker (reclaimed after keepAliveTime).
4. Otherwise reject: AbortPolicy (throws), CallerRunsPolicy (caller executes, natural backpressure), DiscardPolicy, DiscardOldestPolicy.

ExecutorService pool = new ThreadPoolExecutor(
    5, 50, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(200),            // bounded: max threads become reachable
    new ThreadPoolExecutor.CallerRunsPolicy()); // slows producers instead of dropping

Under a spike with the unbounded queue the symptom is rising latency and heap (queued tasks), not rejected tasks. With a bounded queue the pool reaches 5 + 50 threads only after 200 tasks are queued.

Composite indexes are sorted by a, then b within a, then c. The leftmost-prefix rule says the index is usable efficiently only for a prefix of the columns.

• a=1: yes, full use.
• b=2: not as an efficient seek (MySQL cannot; PostgreSQL may do a full index scan, MySQL 8.0 has skip scan in limited cases).
• a=1 AND c=3: seeks on a, then c is only filtered inside the range of a (an index condition, not a seek).
• a=1 AND b>5 AND c=3: seeks on a and range on b; c cannot narrow the range because after a range predicate the following columns are not sorted contiguously.

Rule of thumb: equality columns first, then the range or sort column, in order of selectivity and query frequency.

CREATE INDEX idx_orders_cust_status_created ON orders (customer_id, status, created_at);

Penetration is repeated requests for keys that exist nowhere (always miss, always hit DB); breakdown is one hot key expiring; avalanche is many keys expiring together or the cache dying, flooding the DB.

• Penetration: cache negative results with a short TTL (for example 30-60 s), validate input, or use a Bloom filter of valid IDs.
• Breakdown: mutex/single flight or logical expiry (see stampede).
• Avalanche: randomize TTLs, multi-layer caches, rate limit and circuit-break DB access, keep Redis highly available, degrade gracefully.
• Bulkhead the DB with a small connection pool so a cache outage queues rather than kills it.

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