Flipkart

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.

Record each expense with a split strategy (equal, exact, percent), update a net balance per user pair, and simplify debts by reducing net balances with a greedy matching.

• Entities: User, Group, Expense (payer, amount, splits), Split, SplitStrategy, BalanceSheet.
• Validation: exact splits sum to total; percentages sum to 100; use long cents and assign the rounding remainder to the payer.
• Simplify: compute each user's net (owed minus owes); repeatedly match the max creditor with the max debtor via two heaps; at most n-1 transactions.

interface SplitStrategy { Map<String, Long> split(long total, List<String> users, Map<String, Long> params); }
class EqualSplit implements SplitStrategy {
    public Map<String, Long> split(long total, List<String> u, Map<String, Long> p) {
        long each = total / u.size(), rem = total % u.size();
        Map<String, Long> m = new LinkedHashMap<>();
        for (int i = 0; i < u.size(); i++) m.put(u.get(i), each + (i < rem ? 1 : 0));
        return m;
    }
}