যেদিন আমরা আমাদের সাইনআপ পাইপলাইন ঠিক করেছিলাম

আমাদের সাইনআপের সংখ্যা প্রতি সপ্তাহে বাড়ছিল। টিম খুব উত্তেজিত ছিল। কিন্তু ডেটা বা উপাত্তগুলো ভুল মনে হচ্ছিল। ব্যবহারকারীরা আর কখনোই ফিরে আসছিল না। ইমেল অ্যাড্রেসগুলো অদ্ভুত দেখাচ্ছিল। আমাদের অ্যাক্টিভেশন রেট কমে যাচ্ছিল।

আমি ডেটাগুলো পরীক্ষা করলাম। আমি সেখানে প্রবৃদ্ধি (growth) খুঁজে পেলাম না। আমি শুধু গোলমাল (noise) খুঁজে পেলাম।

সমস্যা

আমি আইপি (IP) অ্যাড্রেস অনুযায়ী সাইনআপগুলোকে গ্রুপ করার জন্য একটি কুয়েরি (query) চালালাম। একটি আইপি অ্যাড্রেস থেকে ২৪ ঘণ্টার মধ্যে শত শত অ্যাকাউন্ট রেজিস্টার করা হয়েছিল। এটি একই ব্রাউজার ফিঙ্গারপ্রিন্ট ব্যবহার করছিল। একটি স্ক্রিপ্ট আমাদের রেজিস্টার এন্ডপয়েন্টে (register endpoint) হিট করছিল। এটি ডিসপোজেবল (throwaway) ইমেল ডোমেইন ব্যবহার করছিল। এটি ছিল একটি বট, কোনো মানুষ নয়।

আমাদের সাইনআপ পাইপলাইনটি পুরোপুরি উন্মুক্ত ছিল।

সমাধান

আমরা একটি স্প্রিন্টের (sprint) মধ্যেই সুরক্ষার তিনটি স্তর তৈরি করেছি।

স্তর ১: থ্রটলিং (Throttling)

আমরা দুই ধরনের রেট লিমিটিং (rate limiting) ব্যবহার করেছি।

স্তর ২: ব্লক লিস্ট (Blocklists)

স্তর ৩: আইপি ব্লক লিস্ট (IP Blocklist)

কিছু আইপি অত্যন্ত জেদি। তারা আমাদের সিস্টেমের একাধিক অংশ অপব্যবহার করে। আমরা একটি হার্ড ব্লক লিস্ট ব্যবহার করি। এই আইপিগুলো থেকে আসা প্রতিটি রিকোয়েস্ট প্রত্যাখ্যান করা হয়। মিডলওয়্যার (middleware) তাৎক্ষণিকভাবে তাদের থামিয়ে দেয়।

ফলাফল

সমাধান করার আগে:

সমাধান করার পরে:

শিক্ষা

প্রবৃদ্ধি মানে কেবল ব্যবহারকারী পাওয়া নয়। এটি হলো প্রকৃত ব্যবহারকারী পাওয়া। আপনার প্রোডাক্ট সংক্রান্ত সিদ্ধান্তগুলো সঠিক ডেটার ওপর নির্ভর করে। আর সেই ডেটা শুরু হয় আপনার রেজিস্ট্রেশন এন্ডপয়েন্ট থেকে।

উৎস: https://dev.to/ogeobubu/the-day-we-fixed-our-signup-pipeline-3664