4.5.5
Intuition Architecture ka ek-line soulSoftware architecture ka matlab hai boundaries decide karna — kaun sa code piece kaun se doosre piece ke baare mein jaanta hai — taaki system changeable, testable, aur scalable rahe jaise-jaise barhta hai.
Neeche har style ek hi sawaal ka alag jawab hai: "System ko kaise kaatein taaki ek jagah change se baaki sab kuch toot na jaaye?"
Architecture ke bina code ek plate spaghetti hai: har line har doosri line ko touch kar sakti hai. Jab aap ek cheez change karte ho, pata nahi kya toot jaayega. Architecture dependencies par direction aur isolation laagoo karti hai taaki:
Aap locally reason kar sako (ek module ko samjho bina poore system ke).
Aap implementations swap kar sako (database badlo, business logic nahi).
Aap teams scale kar sako (har team ek boundary ki maalik hoti hai).
Cost: indirection. Har boundary jo aap add karte ho woh glue code likhne ki jagah hai. Isliye architecture hamesha coupling aur overhead ke beech ek trade-off hai, kabhi "jyada better nahi."
System ko horizontal layers mein split kiya jaata hai, har ek sirf apne seedhe neeche wale layer ko call kar sakti hai. Classic 4 layers:
Presentation (UI / API)Application/Service (use-case orchestration)Domain/Business logic Data access / Persistence
WHY yeh shape? Kyunki concerns alag-alag rates par change hote hain . UI baar-baar change hoti hai; database schema bahut kam. Inhe separate karke, ek UI redesign persistence code ko touch nahi karta.
HOW rule kaam karta hai: dependencies sirf neeche ki taraf point karti hain. Presentation, Service ke baare mein jaanti hai; Service, Data ke baare mein; Data, apne upar kisi ke baare mein nahi. Yeh "closed layers" hai — aap koi layer skip nahi kar sakte.
Common mistake "Layered = scalable"Yeh sahi kyun lagta hai: layers clean aur organized dikhti hain, isliye log sochte hain yeh scale mein help karti hain.
Fix: layers maintainability mein help karti hain, raw scalability mein nahi — poori cheez phir bhi aksar ek process (ek monolith) ke roop mein deploy hoti hai. Scale karne ke liye, aap poora stack replicate karte ho, sirf ek layer nahi. Organizational separation ko deployment separation samajhne ki galti mat karo.
Intuition WHY teen pieces mein split karein?Kyunki same data (Model) kai tarikoon se dikhaya ja sakta hai (ek table, ek chart, ek JSON API). Agar rendering code data code ke saath ulajha hua hai, toh aap data ko reuse nahi kar sakte. MVC Model ko single source of truth banata hai aur Views ko aane-jaane deta hai.
Worked example Web app mein ek click
User form submit karta hai → request Controller ko hit karti hai. Yeh step kyun? Controller ek akela piece hai jo raw user input ko touch karta hai.
Controller validate karta hai aur Model methods call karta hai (order.save()). Kyun? Business rules Model mein rehte hain, Controller mein nahi.
Controller ek View select karta hai aur usse updated Model deta hai. Kyun? Taaki Controller decide kare "kya dikhana hai," View decide kare "kaise dikhana hai."
View Model data se HTML render karta hai. Kyun? Presentation logic ko isolated aur swappable rakhta hai.
Common mistake "Fat controllers"Yeh sahi kyun lagta hai: Controller woh jagah hai jahan request land hoti hai, isliye wahan business logic likhna tempting lagta hai.
Fix: Controllers thin routers hone chahiye; logic Model/Service mein belong karta hai. Ek fat controller ko poore web layer ko fake kiye bina unit-test nahi kiya ja sakta.
Components ek doosre ko directly call karne ki jagah ek channel (broker/queue) ke through events produce aur consume karke communicate karte hain. Ek producer nahi jaanta kaun consume karta hai; consumer nahi jaanta kisne produce kiya.
Intuition WHY events ke zariye decouple karein?Direct calls synchronous aur tightly coupled hote hain: A, B ko call karta hai, A, B ka wait karta hai, A ko B ka address pata hona chahiye. Events ke saath, A bas ek broker mein "OrderPlaced!" chillaata hai. Jo bhi parwaah karta hai (email service, inventory, analytics) sunata hai. Nayi reaction add karne ke liye, aap nayi consumer add karte ho — A kabhi nahi badalti. Yeh layered ke rigid downward calls ka ulta hai.
Common mistake "Events se sab kuch simpler ho jaata hai"Yeh sahi kyun lagta hai: decoupling purely achha lagtaa hai.
Fix: aap spatial coupling ko temporal complexity se trade karte ho. Ab aap eventual consistency , mushkil debugging (services ke across koi stack trace nahi), aur ordering / duplicate problems face karte ho. Events kai independent reactions ke liye shine karte hain; simple request–response ke liye hurt karte hain.
System ko kai chhoti, independently deployable services mein split kiya jaata hai, har ek ek business capability aur apna database own karti hai, network (HTTP/gRPC/events) ke zariye communicate karti hain.
Intuition WHY ek monolith ko services mein split karein?Teen real drivers:
Independent deployment — payments team ka change deploy karo bina sab kuch redeploy kiye.Independent scaling — sirf load wali service (jaise search) scale karo poori app ki jagah.Team autonomy — Conway's law: aapki architecture aapke org ko mirror karti hai, isliye har team ko ek service do.
HOW boundary draw ki jaati hai: ek business capability (Orders, Payments, Shipping) ke around, na ki ek technical layer ke. Har service apna data own karti hai; koi doosri service directly uska database touch nahi kar sakti.
Common mistake "Microservices pehle"Yeh sahi kyun lagta hai: bade companies inhe use karti hain, toh yeh best practice hona chahiye.
Fix: microservices network latency, distributed transactions, aur operational cost (N services deploy/monitor karna) add karte hain. Ek chhoti team ke liye ek well-structured monolith faster aur sasta hai. Classic advice: modular monolith se shuru karo, split tabhi karo jab ek boundary ko genuinely independent scaling/deployment chahiye ho.
Monolith
Microservices
Deploy unit
ek
kai
Database
shared
per-service
Failure
all-or-nothing
isolated
Complexity
code mein
network/ops mein
Aap chhote functions (Functions-as-a-Service) likhte ho; cloud provider unhe on demand chalata hai, automatically zero se scale karta hai aur sirf actual execution time ke liye bill karta hai. Aap koi server manage nahi karte.
Intuition WHY serverless exist karta haiZyaadaatar servers zyaadaatar time idle rehte hain par aap phir bhi 24/7 pay karte ho. Serverless yeh ulta kar deta hai: code sirf tab run hota hai jab ek event trigger karta hai, aur aap per invocation × duration pay karte ho. Idle cost ≈ 0. Yeh event-driven thinking ka natural evolution hai jo infrastructure level tak push ho gayi hai.
Common mistake "Serverless ka matlab koi server nahi aur koi limit nahi"Yeh sahi kyun lagta hai: naam kehta hai "serverless."
Fix: servers phir bhi exist karte hain — sirf aap unhe manage nahi karte. Aapko real limits milti hain: cold starts (zero se scale karte waqt latency), execution time caps , statelessness (calls ke beech koi local memory nahi), aur vendor lock-in . Spiky/event work ke liye great, long-running stateful jobs ke liye poor.
Worked example Pehle forecast karo, phir jawab padhoEk startup ek internal CRUD admin tool banaata hai, 5 users.
Forecast: kaun sa architecture? …
Verify: Ek layered monolith (ya MVC web app). Low traffic, ek team — microservices/serverless overhead bilkul waste hai. Problem ke hisaab se complexity match karo.
Worked example Black-Friday e-commerce, 50 teamsForecast: …
Verify: Microservices + event-driven (checkout vs catalog ki independent scaling; async order processing), possibly serverless spiky image-thumbnail jobs ke liye. Org ka size aur load overhead justify karta hai.
Recall Active recall — answers dhako
Kaunse do metrics ko SAARI architecture optimize karne ki koshish karti hai? ::: low coupling , high cohesion .
Layered mein, dependencies kis direction mein point kar sakti hain? ::: sirf neeche ki taraf .
MVC mein, kaun sa component business rules hold karta hai? ::: Model .
Event-driven O ( n ⋅ m ) O ( n + m )
Microservice boundaries kis ke around draw ki jaati hain? ::: business capabilities ke, har ek ka apna database hota hai.
Serverless idle cost approximately kitna hota hai? ::: zero (pay per invocation).
Recall Feynman: 12-saal ke bacche ko samjhaoLEGO se build karna imagine karo. Layered ek cake hai — har floor neeche wale par baithti hai aur sirf apne neighbour se baat karta hai. MVC ek puppet show hai: puppet (Model) asli cheez hai, stage (View) use dikhata hai, puppeteer (Controller) audience ke reactions par react karta hai. Event-driven ek school bell hai: yeh bajti hai, aur jo bhi care karta hai (lunch lady, teacher) react karta hai — bell nahi jaanti kaun sun raha hai. Microservices ek badi kitchen ki jagah kai chhote food stalls hain — har ek ek dish banata hai aur apne aap khul/band ho sakta hai. Serverless ek kitchen ko minute ke hisaab se rent karna hai: aap sirf tab khaana banate ho jab order aata hai, sirf un minutes ke liye pay karte ho, aur koi aur clean up karta hai.
Mnemonic Inhe independence ke hisaab se order karo"Little Mice Eat Many Snacks" → L ayered, M VC, E vent-driven, M icroservices, S erverless — roughly increasing mein ki pieces kitne independently deploy aur scale hote hain.
Software architecture fundamentally kya decide karti hai? Boundaries kahan jaayenge — kaun se modules kaun par depend kar sakte hain — system ko changeable, testable, scalable rakhne ke liye.
Coupling aur cohesion define karo aur har ek ka goal batao. Coupling = inter-module dependence (low chahiye); cohesion = intra-module relatedness (high chahiye).
Layered architecture mein dependency rule kya hai? Har layer sirf apne seedhe neeche wali layer ko call karti hai; dependencies sirf neeche point karti hain.
Ek layered app aksar scale karna mushkil kyun hota hai? Yeh typically ek process (monolith) ke roop mein deploy hota hai; aap poora stack replicate karte ho, ek layer nahi.
MVC ke teen components aur unke kaam kya hain? Model = data+rules, View = render karta hai, Controller = input handle karta hai aur orchestrate karta hai.
"Fat controller" anti-pattern kya hai aur iska fix kya hai? Business logic controller mein daalna; fix hai controllers ko thin rakhna aur logic Model/Service mein daalna.
Event-driven architecture connection complexity kaise reduce karta hai? O(n·m) direct links se O(n+m) ho jaata hai broker ke through route karke; producers/consumers ek doosre ko nahi jaante.
Event-driven architecture kaun si mushkil problem introduce karta hai? Temporal coupling: eventual consistency, ordering, duplicates, mushkil distributed debugging.
Microservice boundaries kis ke around draw ki jaani chahiye? Business capabilities ke, har ek apna database own karta hai — technical layers ke nahi.
Microservices ke monolith se compare karte waqt do costs batao. Network latency + distributed transactions, aur kai services deploy/monitor karne ka operational cost.
Microservices se pehle recommended starting point kya hai? Ek modular monolith; ek service tab hi split karo jab ek boundary ko truly independent scaling/deployment chahiye ho.
Serverless (FaaS) kya automate karta hai aur iska billing kaise hota hai? Functions ko demand par zero se auto-scale karta hai; per invocation × duration (GB-seconds) bill hota hai.
Serverless ki teen real limits batao. Cold-start latency, execution time caps / statelessness, aur vendor lock-in.
Serverless cost reserved server se kab better hoti hai? Bursty/low-volume workloads ke liye jahan idle cost (≈0) dominant ho; steady high volume ke liye reserved servers better hain.
Coupling and Cohesion Monolith vs Microservices Message Queues and Brokers Eventual Consistency Conway's Law Design Patterns — MVC, Observer Scalability — Horizontal vs Vertical Cloud Computing — IaaS PaaS FaaS
Dependencies point down only
