Module 2 এর ৫টা lesson শেষ — DNS, TCP/UDP/TLS, REST/GraphQL/gRPC, WebSocket/SSE/Long Polling, আর API Design at Scale। এই Exit Challenge এ এই সবগুলো concept একসাথে, একটা বাস্তবসম্মত scenario তে প্রয়োগ করতে হবে।
১. Mini Design Challenge (Tier 3)
Scenario: TaskFlow এখন সফল, এবং একটা বড় সিদ্ধান্ত নিয়েছে — তৃতীয় পক্ষের (third-party) developer দের জন্য একটা Public Integration API চালু করবে। এর মাধ্যমে partner রা (যেমন Slack, Zapier, বা কোনো company নিজেদের internal tool থেকে) TaskFlow এর task তৈরি, তালিকা দেখা এবং update করতে পারবে।
এর পাশাপাশি, একটা নতুন internal admin feature ও আসছে — "Live Partner Activity Monitor", যেখানে TaskFlow এর নিজের team দেখতে পারবে কোন partner API কতগুলো request পাঠাচ্ছে, real-time এ, একটা dashboard এ।
তোমার কাজ — নিচের প্রতিটা প্রশ্নে Module 2 এর concept প্রয়োগ করে সিদ্ধান্ত নাও এবং reasoning দাও:
১. API Paradigm (Lesson 2.3) Partner-facing API এর জন্য REST, GraphQL, নাকি gRPC বেছে নেবে? তোমার lesson এর "৩টা প্রশ্ন" framework ব্যবহার করে যুক্তি দাও।
২. Versioning + Pagination (Lesson 2.5)
Partner রা GET /tasks call করে সব task এর তালিকা পাবে। এই endpoint এর জন্য:
- কোন versioning strategy ব্যবহার করবে?
- Offset নাকি cursor-based pagination? কেন (নির্দিষ্টভাবে এই partner-API context এ চিন্তা করো — partner রা কীভাবে এই endpoint ব্যবহার করবে সেটা ভাবো)?
৩. Idempotency (Lesson 2.5)
Partner রা POST /tasks দিয়ে নতুন task তৈরি করতে পারবে। এখানে Idempotency Key pattern কীভাবে প্রযোজ্য? এই ক্ষেত্রে যদি একই key তে ভিন্ন body আসে, সেটা কীভাবে handle করা উচিত (তোমার নিজের হাতে-কলমে করা exercise থেকেই উত্তর দাও)?
৪. Real-time Mechanism (Lesson 2.4) "Live Partner Activity Monitor" এর জন্য — WebSocket, SSE, নাকি Long Polling? Bidirectional প্রয়োজনীয়তা বিবেচনা করে সিদ্ধান্ত নাও এবং কারণ দাও।
৫. Transport এবং Security (Lesson 2.1, 2.2)
Partner রা api.taskflow.app নামে একটা নতুন subdomain ব্যবহার করবে।
- এই নতুন subdomain এর DNS TTL নিয়ে (launch এর সময়) কী চিন্তা করবে?
- TLS এর ক্ষেত্রে কোন version(গুলো) সাপোর্ট করবে (Lesson 2.2 এর ২০২৬ standard মনে করে)?
৬. Error Contract (Lesson 2.5)
Partner যদি একটা invalid task ID দিয়ে GET /tasks/:id call করে (task টা exist করে না), তাহলে error response এর একটা concrete JSON example লেখো, তোমার lesson এর error contract format অনুসরণ করে।
মনে রাখার একটা কথা: প্রতিটা উত্তরে শুধু "কী বেছে নিলাম" না, "কী ছাড় দিচ্ছি" সেটাও এক লাইনে বলার চেষ্টা করো — এটাই তোমার Module 2 জুড়ে মূল improvement area ছিল (2.3 এর GraphQL answer থেকে শুরু করে)।
আমি এটা প্রতিটা ধাপ ধরে ধরে critique করব।
২. Self-Check — এই Module শেষে তুমি এগুলো পারার কথা
- [ ] URL থেকে response আসা পর্যন্ত DNS lookup এর পুরো chain (Recursive/Iterative, TTL) ব্যাখ্যা করতে পারি
- [ ] TCP vs UDP কখন কোনটা উপযুক্ত, উদাহরণসহ বলতে পারি
- [ ] TLS handshake এর ধাপ, এবং TLS 1.2 vs 1.3 এর round-trip পার্থক্য বুঝি
- [ ] REST, GraphQL, gRPC — এই তিনটার মধ্যে সঠিক পছন্দ, constraint অনুযায়ী (hype না) করতে পারি
- [ ] Over-fetching/Under-fetching, N+1 Problem এই টার্মগুলো সঠিক প্রসঙ্গে ব্যবহার করতে পারি
- [ ] WebSocket, SSE, Long Polling এর মধ্যে bidirectional-ity এবং frequency এর ভিত্তিতে সিদ্ধান্ত নিতে পারি
- [ ] Offset vs Cursor pagination এর trade-off এবং কখন কোনটা বলতে পারি
- [ ] Idempotency Key pattern নিজে হাতে implement করতে পারি (legitimate retry vs payload mismatch এর পার্থক্য সহ) — এটা তুমি আজকে verified code দিয়ে প্রমাণ করেছ
- [ ] একটা সামঞ্জস্যপূর্ণ Error Contract ডিজাইন করতে পারি
তোমার Idempotency Key hands-on exercise টা দেখে বলা যায় — শেষ বক্সটা নিয়ে তোমার কোনো সন্দেহ থাকার কথা না, ওটা তুমি বাস্তবে verify করে দেখিয়েছ।
৩. Recommendation
পড়ার জন্য:
- Stripe এর নিজস্ব Idempotency Keys documentation — তোমার আজকের exercise এর সাথে সরাসরি তুলনা করে দেখতে পারবে, বাস্তব production system এ ঠিক কী কী edge case handle করা হয় (যেমন, concurrent request একই key দিয়ে একসাথে এলে কী হয় — এটা তোমার current in-memory implementation এ handle হয় না, কারণ সেটার জন্য locking/atomic operation লাগে, যেটা আমরা পরে database transaction context এ শিখব)
দেখার জন্য:
- gRPC এর official "Basics tutorial" (grpc.io তে) — Node.js/TypeScript দিয়ে একটা ছোট service বানানোর হাতে-কলমে গাইড, Module 9 এর আগে familiarity তৈরি করতে সাহায্য করবে
Project এর জন্য:
- নিজের সময়ে (course এর বাইরে) — তুমি আগে লেখা কোনো payment-related endpoint এ যদি idempotency key implement করা না থাকে, আজকের pattern টা (হ্যাশ-ভিত্তিক payload comparison + TTL) সেখানে সরাসরি প্রয়োগযোগ্য, শুধু in-memory Map এর জায়গায় Redis ব্যবহার করতে হবে (persistence এবং multi-instance এর জন্য, Lesson 1.6 এর stateless নীতি মনে করে)
Exit challenge টা করে পাঠাও। রেডি হলে next লিখলে আমরা Module 3: Load Balancing & Proxies এ যাব — Lesson 3.1 দিয়ে শুরু, যেখানে TaskFlow প্রথমবারের মতো সত্যিকারের multi-server architecture তে যাবে, এবং তোমার Lesson 1.6 এর "Stateless" জ্ঞান এখানে সরাসরি কাজে লাগবে।