PhonePe

Java 7 used 16 lock-striped Segments (each a ReentrantLock over a mini hash table). Java 8+ removed segments: an empty bucket is filled with a lock-free CAS; otherwise it uses synchronized on the bucket's first node. Resizing is cooperative (multiple threads migrate bins), and bins treeify like HashMap.

• Reads are lock-free (volatile fields); size() uses striped CounterCells (like LongAdder), so it is an estimate under concurrency.
• No null keys or values.

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.

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.

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;
    }
}

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.