🌐 Request එකක ගමන: DNS → TCP → TLS → HTTP → App → DB

☕ හැඳින්වීම: Enter එක ඔබපු තත්පරයේ මොකද වෙන්නේ?

ඔයා phone එකෙන් daraz.lk කියලා type කරලා Enter ඔබනවා. තත්පරයකටත් අඩු කාලෙකින් page එක load වෙනවා. ඒක හරිම සාමාන්‍ය දෙයක් වගේ පේනවා නේද? 🤔

ඒත් ඇත්තටම ඒ මිලි තත්පර කීපය ඇතුළේ ලොකු ගමනක් යනවා. ඔයාගේ request එක (server එකකින් යමක් ඉල්ලන පණිවිඩය) ලෝකයේ කොහේ හරි තියෙන server එකක් හොයාගෙන, ආරක්ෂිත පාරක් හදාගෙන, data ගෙනත් ආපහු ඔයාගේ screen එකට එනවා. 🚀

මේක හිතන්න කොළඹ ඉඳන් ගාල්ලේ යාළුවෙකුට ලියුමක් යවනවා වගේ:

• 📒 මුලින්ම ලිපිනය හොයාගන්න ඕනේ (DNS)
• 📞 ඊට පස්සේ "මම ලියුමක් එවනවා, ලැබුණොත් කියන්න" කියලා confirm කරගන්නවා (TCP)
• 🔐 කවුරුත් කියවන්න බැරි වෙන්න ලියුම seal කරනවා (TLS)
• ✉️ ලියුම ඇතුළේ මොනවද ඕනේ කියලා ලියනවා (HTTP)
• 🧑‍💼 යාළුවා ලියුම කියවලා වැඩේ කරනවා (App)
• 🗄️ ඒකට අවශ්‍ය විස්තර ලිපිගොනුවෙන් හොයනවා (Database)

මේ blog එකෙන් අපි මේ හැම පියවරක්ම zero ඉඳන් architect level එක වෙනකම් කතා කරමු. Interview එකකදී අහන ජනප්‍රියම ප්‍රශ්නයක් වන "What happens when you type a URL in the browser?" එකටත් මේකෙන් හොඳ උත්තරයක් ලැබෙයි. 💡

🗺️ මුළු ගමනම එක බැල්මකින්

විස්තර වලට යන්න කලින්, මුළු ගමනම පියවර 6කින් බලමු:

1. DNS 📒 — daraz.lk කියන නම, computer වලට තේරෙන IP address එකකට (උදා: 104.18.20.35) හරවනවා.
2. TCP 🤝 — ඔයාගේ device එකයි server එකයි අතර විශ්වාසදායක connection එකක් හදනවා.
3. TLS 🔐 — ඒ connection එක encrypt කරලා, අතරමැද කාටවත් කියවන්න බැරි කරනවා.
4. HTTP ✉️ — "මට home page එක දෙන්න" වගේ ඇත්ත ඉල්ලීම යවනවා.
5. App ⚙️ — server එකේ තියෙන code එක request එක තේරුම් අරන් logic run කරනවා.
6. DB 🗄️ — අවශ්‍ය data database එකෙන් අරන් app එකට දෙනවා.

ඊට පස්සේ උත්තරය ආපු පාරෙම ආපහු ඔයාගේ browser එකට ගිහින් screen එකේ පෙන්නනවා. 🔁

පියවර	Sri Lankan analogy 🇱🇰	ප්‍රශ්නයට දෙන උත්තරය
DNS	1919 ට call කරලා කඩේ ලිපිනය අහනවා	"කොහෙද?"
TCP	කඩේට call කරලා "ඇහෙනවද?" "ඔව් ඇහෙනවා"	"සම්බන්ධ වෙලාද?"
TLS	රහස් code වචනයක් එකඟ වෙනවා	"ආරක්ෂිතද?"
HTTP	"කොත්තු එකක් එවන්න" කියලා order එක දෙනවා	"මොකක්ද ඕනේ?"
App	කඩේ බාස් order එක හදනවා	"කොහොමද කරන්නේ?"
DB	ගබඩාවෙන් බඩු ගන්නවා	"data කොහෙද?"

📒 පියවර 1: DNS — Internet එකේ දුරකථන නාමාවලිය

මොකක්ද DNS?

DNS (Domain Name System) කියන්නේ website නම් (උදා: google.com) IP address වලට හරවන system එක. Computer වලට නම් තේරෙන්නේ නෑ, ඒවට තේරෙන්නේ අංක විතරයි. 🔢

අපි phone එකේ "අම්මා" කියලා save කරලා තියෙනවා, අංකය මතක තියාගන්නේ නෑ. DNS කරන්නෙත් ඒකමයි — Internet එකේ contact list එක. 📱

කොහොමද DNS වැඩ කරන්නේ? ⚙️

ඔයා www.daraz.lk type කළාම, browser එක මේ විදියට පිළිතුර හොයනවා:

1. Browser cache — "මම කලින් මේක හොයලා තියෙනවද?" බලනවා.
2. OS cache — Operating System එකේ මතකය බලනවා.
3. Recursive Resolver — සාමාන්‍යයෙන් ඔයාගේ ISP එකේ (Dialog, SLT වගේ) හෝ 8.8.8.8 වගේ public DNS server එකක්. මෙයා තමයි ඔයා වෙනුවෙන් හොයන "අතරමැදියා".
4. Root Server — ".lk ගැන දන්නේ මෙයා" කියලා TLD server එකට යොමු කරනවා.
5. TLD Server (.lk) — "daraz.lk ගැන දන්නේ මෙයා" කියලා Authoritative server එකට යොමු කරනවා.
6. Authoritative Server — අවසාන උත්තරය, ඇත්ත IP address එක දෙනවා. ✅

මේක හරියට බස් එකේ කොන්දොස්තර මහත්තයගෙන් පාර අහනවා වගේ: "ගාල්ලට යන්න මාතර බස් එකට නගින්න", "කොටුවේ බහින්න", "එතනින් වම් පැත්තට". හැම කෙනෙක්ම ඊළඟ පියවර කියනවා. 🚌

TTL සහ Caching 💾

හැම පාරම මේ මුළු ගමන යන එක මන්දගාමී නිසා, උත්තරය ටික කාලයක් cache කරනවා. ඒ කාලයට කියන්නේ TTL (Time To Live) — උත්තරය මතක තියාගන්න පුළුවන් තත්පර ගණන.

daraz.lk.   300   IN   A   104.18.20.35
#           ↑ TTL = තත්පර 300 (විනාඩි 5)

Command line එකෙන් ඔයාටම try කරන්න පුළුවන්:

nslookup google.com
dig google.com +trace

💡 Pro Tip: Server එකක් migrate කරන්න කලින් දවසකට කලින් TTL එක 60s වගේ අඩු කරන්න. එතකොට IP එක මාරු කළාම ඉක්මනින්ම හැමෝටම අලුත් IP එක ලැබෙනවා.

⚠️ Common Mistake: "DNS change කළා, ඒත් වැඩ කරන්නේ නෑ!" කියලා කලබල වෙනවා. බොහෝවිට පරණ TTL එක ඉවර වෙනකම් cache එකේ පරණ IP එක තියෙනවා. ඉවසන්න ⏳

🤝 පියවර 2: TCP — "ඇහෙනවද?" "ඔව් ඇහෙනවා!"

මොකක්ද TCP?

TCP (Transmission Control Protocol) කියන්නේ data නැති නොවී, පිළිවෙලට, නිවැරදිව යවන්න හදපු නීති මාලාවක් (protocol එකක්). IP address එක දැන් අපි ළඟ තියෙනවා, ඒත් කතා කරන්න කලින් connection එකක් හදාගන්න ඕනේ.

3-Way Handshake 🤝

TCP connection එකක් පටන් ගන්නේ පණිවිඩ 3කින්:

1. SYN — Client: "හලෝ, කතා කරන්න පුළුවන්ද?"
2. SYN-ACK — Server: "ඔව්, මට ඇහෙනවා. ඔයාට මාව ඇහෙනවද?"
3. ACK — Client: "ඔව් ඇහෙනවා, පටන් ගමු!" ✅

අපේ ගම්වල phone call එකක් හිතන්න: "හලෝ... ඇහෙනවද?" "ආ ඔව් ඔව් ඇහෙනවා, ඔයාට මාව ඇහෙනවද?" "ඔව්, හරි දැන් කියන්න." 📞 ඒක තමයි 3-way handshake එක!

Port කියන්නේ මොකක්ද? 🚪

IP address එක ගොඩනැගිල්ලේ ලිපිනය නම්, port එක කියන්නේ කාමර අංකය. එකම server එකේ services ගොඩක් දුවනවා, port එකෙන් තමයි හරි service එකට යන්නේ.

• Port 80 → HTTP
• Port 443 → HTTPS
• Port 5432 → PostgreSQL database
• Port 3306 → MySQL database

TCP එකේ සුපිරි හැකියාවන් 💪

• Reliability — packet එකක් නැති වුණොත් ආපහු යවනවා.
• Ordering — packets අවුල් පිළිවෙලට ආවත් හරි පිළිවෙලට හදනවා.
• Flow control — receiver එකට දරාගන්න බැරි වේගෙන් යවන්නේ නෑ.

💡 Pro Tip: Handshake එකට round trip එකක් (යන්න-එන්න යන කාලය) යනවා. කොළඹ ඉඳන් Singapore server එකකට 40ms විතර, US server එකකට 200ms+ වෙන්න පුළුවන්. ඒ නිසා users ලාට ළඟ server (region) තෝරන්න.

⚠️ Common Mistake: හැම request එකකටම අලුත් TCP connection එකක් හදන එක. Keep-alive පාවිච්චි කරලා connection එක reuse කරන්න — handshake එකේ වියදම එක පාරයි.

🔐 පියවර 3: TLS — රහස් කතාව ආරක්ෂා කරන අගුල

මොකක්ද TLS?

TLS (Transport Layer Security) කියන්නේ ඔයාගේ device එකයි server එකයි අතර යන data encrypt කරන (කාටවත් කියවන්න බැරි කේතයකට හරවන) protocol එක. Browser එකේ 🔒 අගුල සහ https:// එකේ තියෙන S එක ආවේ TLS නිසා.

TLS නැතුව ඔයා café WiFi එකකින් bank එකට login වුණොත්, ඒ network එකේ ඉන්න ඕනෑම කෙනෙක්ට password එක කියවන්න පුළුවන්. 😱

TLS Handshake එකේ ප්‍රධාන දේවල් 3ක්

1. Server එක කවුද කියලා ඔප්පු කරනවා 🪪 — Server එක certificate එකක් පෙන්නනවා. ඒක Let's Encrypt, DigiCert වගේ විශ්වාසවන්ත Certificate Authority (CA) එකක් sign කරලා තියෙන්නේ. හරියට NIC එක වගේ: රජය නිකුත් කළ නිසා අපි විශ්වාස කරනවා.
2. Encryption ක්‍රමය එකඟ වෙනවා 🤝 — දෙගොල්ලෝම support කරන හොඳම algorithm එක තෝරනවා.
3. Session key එකක් හදාගන්නවා 🔑 — Public-key cryptography පාවිච්චි කරලා, අතරමැද කෙනෙක්ට නොදැනෙන්න රහස් key එකක් හදාගන්නවා. ඊට පස්සේ හැම data එකක්ම ඒ key එකෙන් encrypt වෙනවා.

TLS 1.2 vs TLS 1.3 ⚡

	TLS 1.2	TLS 1.3
Handshake round trips	2	1
Repeat visits	1	0 (0-RTT)
පරණ, දුර්වල algorithms	Allowed	ඉවත් කරලා

TLS 1.3 නිසා HTTPS දැන් HTTP තරම්ම වේගවත්. ඉතින් "HTTPS slow" කියන කතාව පරණයි! 🚀

💡 Pro Tip: Production වල TLS 1.2 ට අඩු versions disable කරන්න, certificates auto-renew වෙන්න සකස් කරන්න (Let's Encrypt + certbot හෝ cloud provider ගේ managed certificates).

⚠️ Common Mistake: Certificate එක expire වෙන දිනය අමතක කරන එක. ලොකු සමාගම් වලටත් මේ නිසා outages වෙලා තියෙනවා. Expiry එකට දින 30කට කලින් alert එකක් දාන්න 📅

✉️ පියවර 4: HTTP — ඇත්ත order එක දෙනවා

මොකක්ද HTTP?

HTTP (HyperText Transfer Protocol) කියන්නේ browser එකයි server එකයි කතා කරන භාෂාව. පාරත් හැදුවා (TCP), ඒක ආරක්ෂිතත් කළා (TLS). දැන් තමයි ඇත්තටම "මට මොකක්ද ඕනේ" කියලා කියන්නේ.

කඩේට ගිහින් "අයියේ, chicken කොත්තු එකක්, ලොකුවට, cheese දාලා" කියනවා වගේ. 🍛

HTTP Request එකක් කොහොමද පේන්නේ?

GET /products/123 HTTP/1.1
Host: www.daraz.lk
User-Agent: Mozilla/5.0 (Android)
Accept: application/json
Cookie: session_id=abc123

• Method (GET) — මොකක්ද කරන්න ඕනේ
• Path (/products/123) — මොන resource එකද
• Headers — අමතර විස්තර (මොන browser එකද, login session එක, ආදිය)
• Body — POST වගේ ඒවායේදී යවන data (උදා: form එකක විස්තර)

ප්‍රධාන HTTP Methods 🛠️

Method	වැඩේ	කඩේ analogy
GET	Data ගන්නවා	Menu එක බලනවා
POST	අලුත් දෙයක් හදනවා	අලුත් order එකක් දෙනවා
PUT / PATCH	තියෙන දෙයක් වෙනස් කරනවා	Order එකට cheese එකතු කරනවා
DELETE	මකනවා	Order එක cancel කරනවා

Status Codes — Server එකේ උත්තරය 📊

• 2xx ✅ සාර්ථකයි — 200 OK, 201 Created
• 3xx ↪️ වෙන තැනකට යන්න — 301 Moved Permanently
• 4xx 🙋 ඔයාගේ වැරැද්ද — 400 Bad Request, 401 Unauthorized, 404 Not Found
• 5xx 🔥 server එකේ වැරැද්ද — 500 Internal Server Error, 503 Service Unavailable

Server එකට කලින්: CDN සහ Load Balancer 🚦

ලොකු systems වල request එක කෙළින්ම app server එකට යන්නේ නෑ:

• CDN (Content Delivery Network) — ලෝකය පුරා විසිරුණු servers. Images, CSS, JS වගේ static files ඔයාට ළඟම තැනින් දෙනවා. Cloudflare, CloudFront වගේ.
• Load Balancer — එන requests app servers ගොඩකට බෙදලා දෙනවා. හරියට bank එකේ "ඊළඟ customer, counter 3 ට" කියන කෙනා වගේ. 🏦

HTTP/1.1 → HTTP/2 → HTTP/3 🚀

• HTTP/1.1 — එක connection එකකින් එක පාරකට එක request එකයි.
• HTTP/2 — එකම connection එකෙන් requests ගොඩක් එකවර (multiplexing).
• HTTP/3 — TCP වෙනුවට QUIC (UDP මත) පාවිච්චි කරනවා. Handshake ඉක්මන්, mobile network මාරු වුණත් connection එක කැඩෙන්නේ නෑ. 📶

⚠️ Common Mistake: Error එකක් ආවත් 200 OK එකක් return කරලා body එකේ "error": true දාන එක. හරි status code එක දාන්න — monitoring tools, caches, clients ඔක්කොම ඒක මත යැපෙනවා.

⚙️ පියවර 5: App — කඩේ කුස්සිය

Request එක server එක ඇතුළට ආවට පස්සේ

Load balancer එකෙන් පස්සේ request එක මුලින්ම යන්නේ reverse proxy එකකට (උදා: Nginx) — app එක ඉදිරියේ ඉන්න දොරටුපාලයා 🚪. ඒක TLS අවසන් කරන්න, compress කරන්න, rate limit කරන්න පුළුවන්. ඊට පස්සේ තමයි ඔයාගේ application server එකට (Node.js, Spring Boot, Django, .NET වගේ) යන්නේ.

App එක ඇතුළේ මොකද වෙන්නේ? 🧠

1. Routing — /products/123 එක හසුරුවන්නේ මොන function එකද කියලා හොයනවා.
2. Middleware — logging, authentication (ඔයා කවුද?), authorization (ඔයාට මේක කරන්න අවසර තියෙනවද?) 🔐
3. Validation — එන data හරිද කියලා check කරනවා.
4. Business logic — ඇත්ත වැඩේ: මිල ගණනය, discount, stock බලනවා.
5. Cache check — "මේ උත්තරය Redis එකේ තියෙනවද?" තියෙනවා නම් DB එකට යන්නේ නෑ ⚡
6. DB call — නැත්නම් database එකෙන් ඉල්ලනවා.
7. Response — JSON හෝ HTML හදලා ආපහු යවනවා.

// Express.js උදාහරණයක්
app.get('/products/:id', authenticate, async (req, res) => {
  const cached = await redis.get(`product:${req.params.id}`);
  if (cached) return res.json(JSON.parse(cached));   // ⚡ Cache hit

  const product = await db.query(
    'SELECT * FROM products WHERE id = $1', [req.params.id]
  );
  if (!product) return res.status(404).json({ message: 'Not found' });

  await redis.set(`product:${req.params.id}`, JSON.stringify(product), 'EX', 60);
  res.json(product);
});

කඩේ බාස් වගේ: order එක කියවනවා, කලින් හදලා තියෙන එකක් තියෙනවද බලනවා (cache), නැත්නම් ගබඩාවෙන් බඩු අරන් (DB) අලුතෙන් හදනවා. 👨‍🍳

💡 Pro Tip: App servers stateless කරන්න — session data server memory එකේ නෙවෙයි, Redis වගේ shared store එකක තියන්න. එතකොට load balancer එකට ඕනෑම server එකකට request යවන්න පුළුවන්, scale කරන්නත් ලේසියි.

⚠️ Common Mistake: N+1 query problem — products 50ක list එකකට, එක query එකක් වෙනුවට queries 51ක් යවන එක. ORM පාවිච්චි කරනකොට විශේෂයෙන් ප්‍රවේශම් වෙන්න.

🗄️ පියවර 6: DB — ගබඩා කාමරය

මොකක්ද Database එකක්?

Database එකක් කියන්නේ data පිළිවෙලට ගබඩා කරලා, ඉක්මනින් හොයාගන්න පුළුවන් system එකක්. PostgreSQL, MySQL වගේ SQL databases tables (Excel sheet වගේ) විදියට data තියාගන්නවා. MongoDB වගේ NoSQL ඒවා documents විදියට.

Query එකක ගමන 🔍

App එක DB එකට query එකක් යැව්වාම:

1. Connection pool එකෙන් connection එකක් ගන්නවා (අලුතෙන් හදන්නේ නෑ).
2. DB එක SQL එක parse කරනවා (තේරුම් ගන්නවා).
3. Query planner එක හොඳම ක්‍රමය තෝරනවා — index එකක් පාවිච්චි කරනවද, මුළු table එකම scan කරනවද?
4. Data disk එකෙන් හෝ memory එකෙන් අරන් result එක app එකට යවනවා.

Index — පොතේ අන්තිම පිටුවේ තියෙන "සූචිය" 📖

Index එකක් නැත්නම්, "product 123" හොයන්න rows ලක්ෂ ගණනක් එකින් එක බලන්න වෙනවා. Index එකක් තියෙනවා නම් තත්පරයෙන් කොටසකින් හොයාගන්නවා. ⚡

CREATE INDEX idx_products_category ON products(category_id);

-- Query එක index එක පාවිච්චි කරනවද බලන්න:
EXPLAIN ANALYZE SELECT * FROM products WHERE category_id = 5;

Connection Pooling 🏊

DB connection එකක් හදන එක වියදම් වැඩක් (TCP + auth + memory). ඒ නිසා connections 10–20ක් කලින්ම හදලා "pool" එකක තියාගෙන, request එන එන විදියට ණයට දීලා ආපහු ගන්නවා. හරියට ත්‍රීවීල් park එකක් වගේ — හැම පාරම අලුත් ත්‍රීවීල් එකක් හදන්නේ නෑ, park එකේ ඉන්න එකක් ගන්නවා. 🛺

ආපහු ගමන 🔁

DB → App (JSON හදනවා) → Load Balancer → TLS encrypt → TCP → ඔයාගේ browser එක → browser එක HTML/CSS/JS render කරලා screen එකේ පෙන්නනවා. 🎉

⚠️ Common Mistake: SELECT * පාවිච්චි කරලා අවශ්‍ය නැති columns 50ක් ගෙන්වන එක, WHERE එකේ පාවිච්චි කරන columns වලට index නොදාන එක. Slow apps වලින් වැඩි ප්‍රමාණයක මූලය මේ දෙකයි.

🇱🇰 Real-World උදාහරණය: ගාල්ලේ ඉඳන් Online Order එකක්

නිමාලි ගාල්ලේ ඉඳන් Dialog 4G එකෙන්, online shop එකක app එකේ "Place Order" button එක ඔබනවා කියලා හිතමු. 📱 Servers තියෙන්නේ Singapore AWS region එකේ.

පළමු පාරට එනකොට කාලය බෙදෙන විදිය (දළ ඇස්තමේන්තුවක්, network එක අනුව වෙනස් වෙනවා):

පියවර	සිදුවෙන දේ	දළ කාලය
DNS	Resolver එකෙන් IP එක හොයනවා	20–100 ms
TCP	Singapore එකට handshake එක	~50 ms
TLS 1.3	Certificate + key exchange	~50 ms
HTTP	POST /orders request එක යවනවා	~50 ms
App	Auth, stock check, payment gateway call	50–300 ms
DB	Order එක save කරනවා (transaction)	5–20 ms

මුළු එකතුව පළවෙනි පාරට 300–600ms විතර. 🤯 ඒත් දෙවෙනි order එකේදී DNS cache වෙලා, TCP/TLS connection එක reuse වෙන නිසා 100–300ms වගේ අඩු වෙනවා.

මෙතනින් පේන වැදගත්ම දේ: network round trips බොහෝවිට DB එකට වඩා වැඩි කාලයක් ගන්නවා. ඒ නිසා ලංකාවේ users ලා target කරන apps වලට Singapore හෝ Mumbai වගේ ළඟ region එකක් තෝරන එක ලොකු වෙනසක්. 🌏

Global උදාහරණ 🌍

• Netflix / YouTube — වීඩියෝ ඔයාට ළඟම CDN server එකෙන් දෙනවා, ඒ නිසා HTTP step එක ලංකාවේ ISP network එක ඇතුළෙන්ම ඉවර වෙන්නත් පුළුවන්.
• Google — HTTP/3 (QUIC) පාවිච්චි කරලා handshake කාලය අඩු කරනවා.
• Banking apps — TLS, certificate pinning, DB transactions ඉතා දැඩිව පාවිච්චි කරනවා, මොකද සල්ලි සම්බන්ධ නිසා 🔐💰

💡 Pro Tip: Chrome DevTools → Network tab → request එකක් click කරලා Timing බලන්න. මේ blog එකේ කතා කරපු හැම පියවරක්ම (DNS lookup, Initial connection, SSL, Waiting/TTFB) ඔයාටම ඇසින් දකින්න පුළුවන්! 👀

🏛️ Architect-Level Insights: අවුරුදු 20ක අත්දැකීමෙන්

මේ ගමන හොඳට තේරුම් ගත්තාම, performance සහ reliability ප්‍රශ්න හොයන්න ඔයාට "X-ray ඇස්" ලැබෙනවා. 🦸 මෙන්න මම ලොකු systems වලදී ඉගෙන ගත්ත දේවල්:

1. හැම step එකක්ම failure point එකක් ⚠️ DNS down වුණොත්, certificate expire වුණොත්, DB connection pool එක පිරුණොත් — ඕනෑම එකකින් මුළු system එකම නවතිනවා. Production incident එකකදී මේ පියවර 6 checklist එකක් විදියට පාවිච්චි කරන්න: "ප්‍රශ්නය මොන hop එකේද?"

2. Latency එකතු වෙනවා, ඒ නිසා round trips අඩු කරන්න 📉 CDN, connection reuse (keep-alive, HTTP/2), TLS 1.3, caching — මේ හැම එකකම අරමුණ එකයි: අනවශ්‍ය ගමන් අඩු කරන එක.

3. Cache කරන්න පුළුවන් හැම layer එකකම cache කරන්න 💾 Browser cache → CDN → Redis → DB buffer cache. Request එකක් DB එකට යන්නම ඕනේ නැත්නම් හොඳම DB query එක තමයි ඒක. ඒත් cache invalidation (පරණ data අයින් කරන එක) ගැන කලින්ම හිතන්න.

4. Timeouts සහ Retries හරියට දාන්න ⏱️ හැම network call එකකටම timeout එකක් දාන්න. Retry කරනකොට exponential backoff (හැම පාරම වැඩි කාලයක් ඉඳලා උත්සාහ කරන එක) පාවිච්චි කරන්න, නැත්නම් කැඩිලා තියෙන service එකක් ඔයාම තවත් කඩනවා.

5. Observability: බලන්න බැරි දේ හදන්න බෑ 🔭 Distributed tracing (OpenTelemetry, Jaeger වගේ) පාවිච්චි කරලා එක request එකක් load balancer → app → DB හරහා යන ගමන ms වලින් බලන්න. Logs, metrics, traces තුනම ඕනේ.

6. ආරක්ෂාව හැම layer එකකම 🔐 DNSSEC, TLS everywhere (internal services අතරත් — mTLS), WAF, parameterized queries (SQL injection වලින් බේරෙන්න), least-privilege DB users. "ඇතුළේ network එක safe" කියලා හිතන්න එපා.

💡 Pro Tip: Interview එකකදී "What happens when you type a URL?" ඇහුවොත්, මේ පියවර 6 කියලා, ඊට පස්සේ "Production එකේදී මම මේ එක එක hop එක monitor කරන්නේ මෙහෙමයි" කියලා කතා කරන්න. Senior candidate කෙනෙක් වෙන් කරලා පේන්නේ එතනින් 😉

⚠️ Common Mistake: "App එක slow" කියලා කෙළින්ම code එක optimize කරන්න පටන් ගන්න එක. මුලින්ම measure කරන්න — බොහෝවිට ප්‍රශ්නය DNS, network distance, හෝ index නැති query එකක්.

✅ Key Takeaways

• 📒 DNS — නම IP address එකකට හරවනවා. TTL සහ caching නිසා දෙවෙනි පාර ඉක්මන්.
• 🤝 TCP — 3-way handshake එකෙන් විශ්වාසදායක connection එකක් හදනවා. Port එක = කාමර අංකය.
• 🔐 TLS — Certificate එකෙන් server එක ඔප්පු කරලා, data encrypt කරනවා. TLS 1.3 = වේගවත් + ආරක්ෂිත.
• ✉️ HTTP — Method, path, headers, body සහ status codes. CDN සහ load balancer අතරමැද ඉන්නවා.
• ⚙️ App — Routing → auth → validation → business logic → cache → DB → response.
• 🗄️ DB — Indexes සහ connection pooling නැතුව scale කරන්න බෑ.
• 🏛️ Architect mindset — හැම hop එකක්ම latency එකක් සහ failure point එකක්. Measure කරන්න, cache කරන්න, round trips අඩු කරන්න.

📚 ඊළඟට ඉගෙන ගන්න ඕනේ මොනවද?

1. OSI Model සහ TCP/IP Model — මේ layers ලෝකය ගැන ගැඹුරින්.
2. Load Balancing Algorithms — Round robin, least connections, consistent hashing.
3. Caching Strategies — Cache-aside, write-through, CDN cache headers (Cache-Control, ETag).
4. Database Scaling — Read replicas, sharding, query optimization.
5. HTTP/3 සහ QUIC — Internet එකේ අනාගතය.
6. Observability — OpenTelemetry, Prometheus, Grafana එක්ක distributed tracing.

🛠️ අද කරන්න පුළුවන් practice එකක්: Terminal එකේ curl -v https://google.com run කරලා output එක කියවන්න. DNS, TCP connect, TLS handshake, HTTP headers ඔක්කොම එතන පේනවා. මේ blog එකේ කතා කරපු ගමන ඔයාගේ ඇස් ඉස්සරහම! 🎯

ප්‍රශ්න තියෙනවා නම් comment එකක් දාන්න. ඊළඟ blog එකෙන් හමුවෙමු! ☕🙏