Swiggy

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

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.

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.

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.

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.

Model ParkingLot with floors of typed spots, issue a Ticket on entry, compute a fee by strategy on exit.

• Requirements: multiple floors, vehicle types (bike, car, truck), spot types, entry/exit gates, hourly pricing, full-lot handling.
• Entities: ParkingLot, Floor, Spot (type, occupied), Vehicle, Ticket, FeeStrategy, SpotAllocationStrategy (nearest, lowest floor).
• Concurrency: two cars must not get the same spot; use an atomic tryOccupy() per spot (CAS) or a lock per floor.
• Extensions: EV charging spots, reservations, payment, display boards (Observer).

class Spot {
    private final AtomicBoolean taken = new AtomicBoolean();
    final SpotType type;
    Spot(SpotType t){ type = t; }
    boolean tryOccupy(){ return taken.compareAndSet(false, true); }
    void free(){ taken.set(false); }
}
class ParkingLot {
    Optional<Ticket> park(Vehicle v, Instant now) {
        for (Floor f : floors)
            for (Spot s : f.spotsFor(v.type()))
                if (s.tryOccupy()) return Optional.of(new Ticket(UUID.randomUUID(), v, s, now));
        return Optional.empty();
    }
}

• Fee: FeeStrategy.compute(Duration) with hourly slabs; pick via vehicle type.
• Keep free spots in a queue per type for O(1) allocation instead of scanning.

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

Treat location updates as a high-volume ephemeral stream (Kafka plus an in-memory geo index), not as rows in the primary database, and push positions to customers over WebSockets. Dispatch queries the geo index for nearby free partners and assigns with an atomic claim.

• Load: 200k active partners pinging every 4 s is about 50k writes/s, far too hot for row updates in an RDBMS.
• Ingest: partner app, then a gateway (WebSocket or gRPC), then Kafka partitioned by partnerId (keeps per-partner ordering); consumers update GEOADD active_partners <lng> <lat> <id> in Redis and write sampled history to cold storage.
• Matching: GEOSEARCH ... BYRADIUS 3 km returns candidates; rank by distance, current load and ETA, then claim one atomically (Lua script or SET partner:{id}:lock NX EX) so two orders cannot take the same partner. Hexagonal cells (H3) or geohash buckets help shard the index by city and compute demand-supply per area.
• Tracking: customer app holds a WebSocket to a push gateway subscribed to the order's channel; the location consumer publishes to it (Redis Pub/Sub or Kafka), bypassing the database.
• Failure handling: expire stale partners with a TTL heartbeat; if a partner rejects or times out, re-run matching with the rejected partner excluded.