এই সপ্তাহে আপনি পাঁচটা বড় ধারণা শিখলেন - cache, queue, security, upload, real-time। আলাদা আলাদাভাবে সবই বুঝেছেন, কিন্তু interviewer আর production দুজনেই দেখতে চায় সব একসাথে একটা project-এ কাজ করছে কিনা। আজকের দিন সেই গাঁথনির।
আজকের কাজ - সপ্তাহ ১-২-এর API-টাকেই বড় করা
- সবচেয়ে বেশি পড়া হয় এমন endpoint-এ (menu বা product list) Redis cache - invalidation সহ
- Order confirm-এর পর email/notification পাঠানো BullMQ queue-তে সরিয়ে দেওয়া
- Helmet চালু, CORS শুধু নিজের domain-এ, login-এ rate limit
- কমপক্ষে একটা endpoint-এ file upload - multer দিয়ে, limit ও type check সহ
- Order status বদলালে Socket.io দিয়ে সংশ্লিষ্ট user-কে live জানানো
গাঁথা শেষ হলে একটা পূর্ণ যাত্রা নিজে হেঁটে দেখুন: login করুন, order দিন, queue দিয়ে notification যাচ্ছে কিনা দেখুন, admin হিসেবে status বদলে customer-এর tab-এ live আপডেট আসছে কিনা দেখুন, আর menu-র দ্বিতীয় request-টা cache থেকে আসছে কিনা সময় মেপে নিশ্চিত হোন। এই এক যাত্রায় পুরো তিন সপ্তাহের কাজ একসাথে পরীক্ষা হয়ে যাবে।
কোথাও আটকালে হতাশ হবেন না - বেশিরভাগ সময় সমস্যাটা ছোট: Redis চলছে তো? Worker আলাদা চালু আছে তো? Environment variable ঠিক আছে তো? Production-এর debug-ও ঠিক এভাবেই হয় - ধাপে ধাপে যাচাই।
সবাই যে ভুলটা করে
নতুন একটা খালি project-এ practice করা। এই সপ্তাহের মর্মই হলো আগের কাজের উপর দাঁড়ানো - আসল চাকরিতেও আপনি সবসময় চলমান কোডের উপরেই নতুন feature গাঁথবেন, ফাঁকা পাতায় নয়।
আজকের Practice
উপরের পাঁচটা কাজ শেষ করে পূর্ণ যাত্রাটা একবার হেঁটে দেখুন। তারপর সপ্তাহের তিনটা interview প্রশ্ন মুখে বলুন: cache invalidation strategy কী হবে, rate limiting কীভাবে implement করবেন, বড় data-তে cursor pagination কেন ভালো।
Interview-এ কীভাবে বলবেন
নিজেকে যাচাই করুন: 'আমার API-তে ঘন ঘন পড়া data Redis-এ cache করা invalidation সহ, ধীর কাজ queue-তে পেছনে চলে, login rate limit দিয়ে সুরক্ষিত, আর order-এর status বদলালে customer Socket.io দিয়ে সঙ্গে সঙ্গে জানে। প্রতিটা অংশ আলাদা দায়িত্ব সামলায়।'