Code10x

HLD system ke components aur unke beech ka interaction decide karta hai — services, databases, queues, load balancers. LLD ek component ke ANDAR ki classes, interfaces, methods aur relationships decide karta hai. HLD "kaunsi service" batata hai, LLD "us service ke andar kaunsi class".

5-8 minute requirements clarify, 5 minute core entities, 10 minute class diagram aur relationships, 15 minute code, 5 minute extensions aur trade-offs. Seedhe code likhna shuru karna sabse badi galti hai.

Noun-verb technique — problem statement ke NOUNS classes bante hain aur VERBS methods. Phir har class se poocho ki uski state (fields) kya hai aur behaviour (methods) kya hai.

Kyunki statement jaanbujhkar adhoora hota hai. Scale, actors, concurrency, persistence aur edge cases poochne se design ek fixed target par banta hai — aur ye seniority ka signal hai, confusion ka nahi.

"Ek class ek kaam" nahi, balki "class badalne ki EK HI WAJAH honi chahiye". OrderService agar order banata hai AND email bhejta hai AND invoice banata hai, to wo teen alag wajah se badlega — teen classes honi chahiye.

Jahan bhi naya type ya naya rule add hone par purani class edit karni pade. Switch-case par fee calculate karna OCP todta hai; FeeStrategy interface banane par naya type ek nayi class ban jaata hai aur purana code chhua tak nahi jaata.

Testing. Agar class ke andar "new RazorpayGateway()" likha hai to test mein asli payment chala jaayega. Interface constructor se lene par test mein FakeGateway inject ho jaata hai — test fast aur safe ho jaate hain.

Dono interface + implementations hain par iraada alag hai. Strategy mein algorithm BAHAR se inject hota hai aur implementations ek doosre ko nahi jaante. State mein object KHUD apna agla state set karta hai — transition ka gyaan implementations ke andar hota hai.

Practically chhe — Strategy (badalta behaviour), Factory (object creation), Singleton (ek instance), Observer (ek event par kai reactions), State (state par behaviour), aur Builder (bahut optional fields). 23 GoF patterns ratne ki zaroorat nahi.

Nahi. Over-engineering utni hi badi galti hai jitni under-engineering. Agar sirf 2 types hain aur kabhi nahi badlenge to Strategy zabardasti hai. Simple solution ko defend karna aana chahiye.

Java mein ENUM singleton — JVM khud guarantee deta hai ki ek hi instance banega, aur ye serialization aur reflection dono se safe hai. Double-checked locking se kaafi simple hai.

ParkingLot → Floor → ParkingSlot ki hierarchy, plus Vehicle, Ticket aur Payment. Do behaviours interface hone chahiye — SlotAllocationStrategy aur FeeStrategy, kyunki dono badalte hain.

Slot assignment ATOMIC honi chahiye — synchronized block, ya ConcurrentHashMap ka putIfAbsent, ya DB par conditional update. Read-then-write karna race condition hai aur do gaadiyon ko ek slot mil jaayega.

External request floor par lage UP/DOWN button se aati hai — usme sirf floor aur DIRECTION pata hoti hai. Internal request lift ke andar ke button se aati hai — usme exact DESTINATION floor pata hota hai. Inhe ek hi model karna design ki badi galti hai.

Lift apni current direction mein aage ke saare stops pehle serve karti hai, aur us direction mein kuch na bache tabhi direction badalti hai. Isse 1→10→2→9 jaisi bekaar bhaag-daud rukti hai. Do TreeSet (upStops ascending, downStops descending) se ye O(log n) mein milta hai.

Kyunki har action ki validity CURRENT STATE par depend karti hai — IDLE mein item select nahi kar sakte, HAS_MONEY mein kar sakte hain. Bina State pattern ke ye nested if-else ka jungle ban jaata hai aur naya state add karna har method ko chhoo jaata hai.

Greedy se bade coin se chhote coin tak. Par asli baat ye hai ki change possible hai ya nahi ye transaction START hone se PEHLE check karna chahiye. Item de dene ke baad "chhutta nahi hai" bolna sabse bura outcome hai.

Chain of Responsibility. ₹2000 handler pehle koshish karta hai, bacha hua amount ₹500 handler ko, phir ₹200, phir ₹100. Naya denomination add karna chain mein ek link jodna ban jaata hai.

Two-phase approach — pehle amount HOLD (reserve) karo, phir physically dispense karo, dispense confirm hone par hold ko actual debit banao. Dispense fail hone par hold release. Bina iske note atakne par customer ka paisa kat jaayega.

Ingredient CHECK aur DEDUCT ek hi atomic operation mein hone chahiye, aur lock POORE ingredient set par lena chahiye. Per-ingredient locks lene par deadlock ban sakta hai — outlet A doodh lock karke cheeni maange aur outlet B ulta.

Recipe ko DATA rakho, code nahi — naam plus ingredient→quantity ka map. Nayi coffee add karna ek config/DB entry ban jaata hai, nayi class aur deploy nahi.

Har row, column, diagonal aur anti-diagonal ke liye ek counter rakho. Player X ke move par +1, O ke move par -1. Kisi bhi counter ka absolute value N ho jaaye to wo player jeeta. Poora board scan karna O(n²) hai aur avoidable hai.

Nahi — dono "Jump" hain (start → end). Ladder mein end > start, snake mein end < start. Ek Map<Integer,Integer> hi kaafi hai aur code aadha ho jaata hai. Do alag classes duplicate logic hai.

Queue/Deque se — player poll karo, khilao, wapas addLast karo. 6 aane par extra turn dena ho to addFirst kar do. Dice ko interface banao taaki test mein deterministic dice inject ho sake.

Har Piece subclass ke andar — abstract Piece class mein abstract canMove(Board, from, to) ho aur King, Queen, Rook, Bishop, Knight, Pawn use implement karein. Board ke andar "if piece instanceof Knight" likhna polymorphism ka pura point kho dena hai.

Saare possible legal moves generate karo, har ek ko SIMULATE karo, aur check karo ki kya koi move king ko safe kar deta hai. Koi nahi kar paaya to checkmate. Simulate ke baad move UNDO karna sabse common bug hai.

Checkmate mein king ABHI attack mein hai aur koi legal move usse bacha nahi sakta — ye haar hai. Stalemate mein king attack mein NAHI hai par koi legal move hai hi nahi — ye DRAW hai. Ye farak bahut candidates miss karte hain.

Seat ko temporarily LOCK karo, permanently nahi. Sabse practical hai Redis mein TTL waala lock — SET NX EX 600. Payment success par LOCKED se BOOKED, aur user bhaag jaaye to TTL apne aap expire ho jaata hai — koi cleanup job nahi chahiye.

Kyunki ek hi physical kursi 6 PM show mein booked aur 9 PM show mein available ho sakti hai. Status SHOW ke context mein hota hai — isliye ShowSeat naam ki alag entity chahiye jo Show aur Seat ko jodti hai.

Date range OVERLAP se — condition hai (start1 < end2) AND (start2 < end1). Available rooms = us type ke total rooms minus overlapping bookings. Ye ek simple boolean flag se nahi ho sakta.

Exclusive. 5 tareekh ko checkout karne waala aur 5 ko check-in karne waala DONO valid hain. Inclusive rakhne par har booking ek extra din ki inventory bewajah block kar degi.

Users RoomType (Deluxe, Suite) book karte hain, actual room number check-in par assign hota hai — real hotels aise hi kaam karte hain. Isse inventory management type-level par hoti hai aur specific room ki maintenance booking ko block nahi karti.

Inventory imbalance — sab log ek direction mein jaate hain aur gaadiyan ek location par jamaa ho jaati hain. Isiliye one-way surcharge lagta hai aur companies rebalancing karti hain. Ye batana business samajh dikhata hai.

SNAPSHOT se. Cart mein add karte waqt ka price lock ho jaana chahiye. Agar Product ka live price padhoge to seller ke price badalne par purane cart aur orders ka amount badal jaayega — ye real e-commerce ka sabse common production bug hai.

Har discount ek DiscountRule ho (applicable + discount methods), aur ek chain mein apply hon. Order matter karta hai — pehle item-level, phir cart-level. Ye order interviewer se clarify karna chahiye.

Network timeout par client retry karega. Bina idempotency key ke wahi payment DOBARA charge ho jaayega. Key ke saath server pehle waala stored result return karta hai — customer ka paisa do baar nahi katta.

Kyunki payment providers at-least-once delivery dete hain — same webhook event kai baar aa sakta hai. Har event ka eventId store karke duplicate ignore karna padta hai, warna ek payment kai baar process ho jaayega.

Reconciliation job se — PENDING payments ko periodically provider se query karke status update karo. Sirf webhook par depend karna production mein reliable nahi hai.

Teen numbers rakho — total, reserved, aur available (= total − reserved). Reserve karte waqt ATOMIC conditional update karo: "UPDATE ... WHERE (total - reserved) >= qty". Read-then-write karna race condition hai.

Place par reserved badhta hai. Ship par total aur reserved DONO ghatte hain. Cancel par sirf reserved ghatta hai. In teen transitions ko sahi likhna hi inventory design ka core hai.

State machine se — PLACED → ACCEPTED → PREPARING → READY → PICKED_UP → DELIVERED. Invalid transitions explicitly block hone chahiye; DELIVERED order dobara PREPARING nahi ho sakta. Har transition par Observer pattern se notifications jaati hain.

DeliveryAssignmentStrategy interface banao. Simplest hai nearest available partner (geohash/quadtree se). Behtar strategy partner ki current direction aur batching bhi dekhti hai. Interface hone se ye upgrade code change nahi maangta.

Geospatial index se — Redis GEO, geohash ya quadtree. Ye O(log n) mein nearby drivers de deta hai. Saare drivers ko linear scan karna galat jawab hai aur scale par bilkul nahi chalega.

15-20 second ka timeout rakho, phir agle driver ko offer jaaye. Driver ka status offer karte waqt ATOMICALLY "OFFERED" hona chahiye, warna wahi driver do rides ke liye offer ho jaayega. Bina timeout ke rider hamesha wait karega.

PricingStrategy interface se — base fare + per km + per minute + surge multiplier, jahan multiplier us area ke demand/supply ratio se aata hai. Strategy hone se pricing model badalna ek nayi class ban jaata hai.

Har vyakti ka NET balance nikaalo, phir greedy se sabse bade deviyar ko sabse bade lenevaale se match karo (max-heap se). A→B 100 aur B→C 100 sirf A→C 100 ban jaata hai. Minimum transactions dhoondhna NP-hard hai — greedy practical approximation hai.

SplitStrategy interface se — EQUAL, EXACT, PERCENTAGE. Har strategy khud VALIDATE bhi kare: exact splits ka jod total ke barabar ho, percentages ka jod 100 ho. Validation bhoolna common galti hai.

Chain of Responsibility — log levels (DEBUG < INFO < WARN < ERROR) ek chain banate hain aur har handler decide karta hai ki message uske level ka hai ya nahi. Appenders (console, file, DB) Strategy pattern se pluggable hote hain.

Do choices hain aur dono ka trade-off batana zaroori hai — message DROP karo (application fast rehti hai par log kho jaata hai) ya caller ko BLOCK karo (koi log nahi khota par app slow ho jaati hai). Ye policy explicitly decide karni padti hai.

HashMap (key → node) plus Doubly Linked List. HashMap se O(1) lookup milta hai aur linked list se node ko O(1) mein head par move kar sakte hain. Eviction ke liye tail ka previous node sabse purana hota hai — wo bhi O(1).

Depend karta hai. LRU temporal locality par achha hai aur naya data jaldi accept karta hai. LFU stable popularity par better hit ratio deta hai par naye items ko punish karta hai (cache pollution) — isliye usme aging/decay lagana padta hai.

Lazy eviction (get par expiry check) plus periodic cleanup thread. Sirf lazy rakhoge to jo entries kabhi access nahi hongi wo expired hokar bhi memory khaati rahengi.

Fixed window — O(1) memory par boundary par 2x burst. Sliding window log — accurate par memory O(requests). Sliding window counter — accuracy aur memory ka balance. Token bucket — burst allow karta hai, API gateways ka default. Trade-off batana hi is sawaal ka core hai.

Limit 100/min ho to user 59th second par 100 aur 61st second par 100 bhej sakta hai — 2 second mein 200 requests, limit ke do guna. Isiliye sliding window ya token bucket use hote hain.

Counter shared hona chahiye — Redis mein. Aur check-and-increment ATOMIC hona chahiye: INCR aur EXPIRE alag commands hain aur beech mein race ho sakti hai, isliye Lua script mein dono ek saath chalao.

NotificationChannel interface (Email, SMS, Push, WhatsApp) plus ek Factory jo channel select kare. User preferences respect karo, aur har channel ka apna template rakho — SMS mein 160 char limit hai, email mein HTML chalta hai.

Exponential backoff (1s, 2s, 4s, 8s) plus JITTER. Jitter isliye ki saare failed messages ek hi second par retry na karein — wo thundering herd problem banata hai. Max retry ke baad dead letter queue.

Nahi. TRANSIENT failure (network down, provider timeout) retry karo. PERMANENT failure (invalid phone number, unsubscribed user) kabhi retry mat karo — wo provider ki rate limit khaa jaata hai aur kabhi succeed nahi hoga.

DelayQueue ya PriorityQueue — tasks execution time se sorted. DelayQueue isliye behtar hai ki wo exact time tak BLOCK karti hai; polling loop (har second check karo) bewajah CPU jalaata hai.

SCHEDULED time se, actual execution time se nahi. Actual time se calculate karoge to har run mein thodi der jodkar DRIFT ho jaayega aur kuch dinon mein schedule pura hil jaayega.

Distributed lock (Redis/Zookeeper) ya DB par atomic claim — task uthane se pehle "claimed" mark karo conditional update se. Bina iske do servers ek hi task uthaa lenge.

Ye policy decide karni padti hai — overlap allow karo, ya skip karo, ya queue karo. Bina policy ke long-running tasks dheere dheere saare worker threads khaa jaate hain.

Book catalogue entry hai (title, author, ISBN) aur BookItem uski PHYSICAL copy hai apne barcode ke saath. Library mein ek book ki 5 copies ho sakti hain. Member Book search karta hai par issue ek BookItem hota hai — ye farak na karna sabse common galti hai.

FIFO queue — copy free hone par queue ke pehle member ko notification jaati hai aur ek HOLD PERIOD (jaise 48 ghante) tak wo copy usi ke liye rakhi rehti hai. Na aaye to agle member par chali jaati hai.

Composite — abstract FileSystemNode, jise File (leaf) aur Directory (composite) extend karte hain. Directory ke andar FileSystemNode ki list hoti hai, isliye nesting aur recursive operations (getSize, delete, search) apne aap kaam karte hain.

File ka SHA-256 content hash nikaalo. Same hash wala blob pehle se ho to naya blob mat likho, sirf reference count badhao. Google Drive aur Dropbox exactly yahi karte hain — isse storage bahut bachta hai.

Parent folder ki permission child par by default apply hoti hai, par child par set ki gayi EXPLICIT permission parent ko override karti hai. Ye real systems ka behaviour hai aur aksar follow-up question banta hai.

Nahi — mehnga hai. DELTA storage (sirf badla hua hissa) ya content-addressed storage use hoti hai, jahan same content ka blob dobara store hi nahi hota. Version metadata (versionId, timestamp, author, contentHash) alag rehta hai.