সফট ডিলিট বনাম হার্ড ডিলিট: সঠিক ডেটা লাইফসাইকেল নির্বাচন করুন

সফট ডিলিট এবং হার্ড ডিলিটের প্রকৃত অর্থ\n\n"ডিলিট" বলতে দুটো একেবারেই ভিন্ন জিনিস বোঝাতে পারে। এগুলো মিশিয়ে দিলে দল ইতিহাস হারায় বা গোপনীয়তার অনুরোধ পূরণে ব্যর্থ হয়।\n\nএকটি হার্ড ডিলিট হল বহু মানুষের যে ধারণা: সারিটি ডাটাবেস থেকে সরিয়ে ফেলা। পরে কুয়েরি করলে তা আর থাকবে না। এটা সত্যিকারের অপসারণ, কিন্তু এটি রেফারেন্স ভেঙে দিতে পারে (যেমন কোনো অর্ডার মুছে ফেলা কাস্টমারের দিকে ইঙ্গিত করে) যদি আপনি ইশতেহার না করেন।\n\nএকটি সফট ডিলিট সারিটি রেখে দেয়, কিন্তু সেটিকে ডিলিট হিসেবে চিহ্নিত করে, সাধারণত deleted_at বা is_deleted মতো ফিল্ড দিয়ে। আপনার অ্যাপ এটি যায় বলা হলেও, রিপোর্ট, সাপোর্ট ও অডিটের জন্য ডেটা থাকে।\n\nসফট ডিলিট বনাম হার্ড ডিলিট-এর পিছনে আর্থিক লেনদেনটি সহজ: ইতিহাস বনাম সত্যিকারের অপসারণ। সফট ডিলিট ইতিহাস রক্ষা করে এবং “আনডু” সম্ভব করে। হার্ড ডিলিট আপনার স্টোরেজ কমায়, যা প্রাইভেসি, নিরাপত্তা এবং আইনি নিয়মের জন্য গুরুত্বপূর্ণ।\n\nডিলেট কেবল স্টোরেজকেই প্রভাবিত করে না। এগুলো বদলে দেয় যে আপনার দল পরে কী উত্তর দিতে পারবে: একটি সাপোর্ট এজেন্ট অতীত অভিযোগ বুঝতে পারবে কিনা, ফাইন্যান্স বিলিং মিলিয়ে নিতে পারবে কিনা, বা কমপ্লায়েন্স কে কি এবং কখন পরিবর্তন করেছে তা যাচাই করতে পারবে কিনা। ডেটা খুব তাড়াতাড়ি বিলীন হলে রিপোর্ট বদলে যায়, টোটাল মিল বন্ধ করে দেয়, এবং তদন্ত অনুমানভিত্তিক হয়ে যায়।\n\nএকটি উপযুক্ত মানসিক মডেল:\n\n- সফট ডিলিট কোন রেকর্ডকে প্রতিদিনের ভিউ থেকে লুকায় কিন্তু ট্রেসেবিলিটির জন্য রাখে।\n- হার্ড ডিলিট একটি রেকর্ড স্থায়ীভাবে সরিয়ে দেয় এবং ব্যক্তিগত ডেটা সংরক্ষণের পরিমাণ কমায়।\n- অনেক বাস্তব অ্যাপ উভয় ব্যবহার করে: ব্যবসায়িক রেকর্ড রাখে, প্রয়োজন হলে ব্যক্তিগত শনাক্তকারী মুছে দেয়।\n\nঅনুশীলনে, আপনি একটি ব্যবহারকারী অ্যাকাউন্ট সফট ডিলিট করতে পারেন যাতে লগইন বন্ধ হয় এবং অর্ডার ইতিহাস অক্ষুণ্ণ থাকে, তারপর রিটেনশন পিরিয়ড বা নিশ্চিত করা GDPR মুছে ফেলার অধিকার অনুরোধের পরে ব্যক্তিগত ক্ষেত্রগুলো হার্ড ডিলিট বা অনামাইজ করতে পারেন।\n\nকোনো টুল আপনাকে এই সিদ্ধান্তটি তুলে দেবে না। এমনকি যদি আপনি AppMaster-র মত নো-কোড প্ল্যাটফর্মে বানান, প্রকৃত কাজ হল প্রতিটি টেবেলের জন্য নির্ধারণ করা যে “ডিলিট” কী মানে এবং নিশ্চিত করা যে প্রতিটি স্ক্রীন, রিপোর্ট এবং API একই নিয়ম অনুসরণ করে।\n\n## প্রতিদিনের অ্যাপগুলোতে ডিলেট কী সমস্যা সৃষ্টি করে\n\nবেশিরভাগ দল কেবল তখনই ডিলেট লক্ষ করে যখন কিছু ভুল হয়। একটি “সরল” ডিলিট প্রসঙ্গ, ইতিহাস এবং ব্যাখ্যা করার ক্ষমতা মুছে দিতে পারে।\n\nহার্ড ডিলিট ঝুঁকিপূর্ণ কারণ এগুলো undo-যোগ্য নয়। কেউ ভুল বোতাম ক্লিক করতে পারে, একটি অটোমেটেড জব বাগ্গযুক্ত হতে পারে, বা সাপোর্ট এজেন্ট ভুল প্লেবুক অনুসরণ করতে পারে। পরিষ্কার ব্যাকআপ এবং রিস্টোর প্রক্রিয়া ছাড়া সেই ক্ষতি স্থায়ী হয়ে যায়, এবং ব্যবসায়িক প্রভাব দ্রুত উপস্থিত হয়।\n\nভাঙা রেফারেন্স পরের আশ্চর্যস্বীকার। আপনি একজন কাস্টমার মুছে ফেললে, তাদের অর্ডারগুলো এখন কোনকিছুতে ইঙ্গিত করবে না। তখন ইনভয়েসে বিলে নাম দেখানো যাবে না, এবং পোর্টাল সম্পর্কিত ডেটা লোড করতে গিয়ে ত্রুটি দেখাতে পারে। এমনকি ফরেন কী কনস্ট্রেইন্ট থাকলে, ফিক্সটি আরও খারাপ হতে পারে: ক্যাসকেডিং ডিলিট আপনি যতটা ভেবেছিলেন তার চেয়ে অনেক বেশি মুছে দিতে পারে।\n\nঅ্যানালিটিক্স ও রিপোর্টিংও গোলমেলে হয়ে যায়। পুরোনো রেকর্ডগুলো বিলীন হলে মেট্রিকস রেট্রোঅ্যাক্টিভলি বদলে যায়। গত মাসের কনভার্শন রেট সরবে, লাইফটাইম ভ্যালু কমবে, এবং ট্রেন্ড লাইনে গ্যাপ দেখা দেয় যা কেউ ব্যাখ্যা করতে পারে না। দল সংখ্যার বিষয়ে তর্কে লিপ্ত হয় পরিবর্তে সিদ্ধান্ত নিতে।\n\nসাপোর্ট ও কমপ্লায়েন্সে আঘাত সবচেয়ে বেশি লাগে। গ্রাহক জিজ্ঞেস করে, “আমি কেন চার্জ হয়েছি?” বা “আমার প্ল্যান কে বদলেছে?” যদি রেকর্ড মুছে যায়, আপনি টাইমলাইন পুনর্নির্মাণ করতে পারবেন না। আপনি সেই অডিট ট্রেইল হারান যা কোনটি, কখন এবং কার দ্বারা পরিবর্তিত হয় তাতে উত্তর দিত।\n\nসফট ডিলিট বনাম হার্ড ডিলিট বিতর্কের সাধারণ ব্যর্থতা মোডগুলো:\n\n- দুর্ঘটনাক্রমে ডিলিট বা বাগযুক্ত অটোমেশন থেকে স্থায়ী ক্ষতি\n- অনুপস্থিত প্যারেন্ট রেকর্ডের কারণে চিলড্রেন orphan থাকা (অর্ডার, টিকিট)\n- ইতিহাসগত সারি বিলীন হওয়ার কারণে রিপোর্টগুলোর পরিবর্তন\n- সাপোর্ট কেসগুলো ইতিহাস ছাড়া অপ্রশ্নযোগ্য হয়ে যাওয়া\n\n## কখন সফট ডিলিট ডিফল্ট হওয়া উচিত\n\nযে রেকর্ডটির দীর্ঘমেয়াদী মূল্য আছে বা অন্য ডেটার সাথে সংযুক্ত আছে সেখানে সফট ডিলিট সাধারণত সবচেয়ে নিরাপদ পছন্দ। সারিটি সরানোর বদলে, আপনি সেটিকে ডিলিট হিসেবে চিহ্নিত করুন (উদাহরণ: deleted_at বা is_deleted) এবং সাধারণ ভিউগুলো থেকে লুকিয়ে রাখুন। সফট ডিলিট এই ডিফল্টটি সাধারণত পরে আশ্চর্য কমায়।\n\nএটি সেই জায়গায় উজ্জ্বল যেখানে আপনাকে ডাটাবেসে একটি অডিট ট্রেইল রাখতে হবে। অপারেশন টিম প্রায়ই সহজ প্রশ্নগুলোর উত্তর দিতে চায়: “who changed this order?” বা “why was this invoice canceled?” যদি আপনি খুব দ্রুত হার্ড ডিলিট করেন, আপনি ফাইন্যান্স, সাপোর্ট এবং কমপ্লায়েন্স রিপোর্টিংয়ের জন্য প্রয়োজনীয় প্রমাণ হারাবেন।\n\nসফট ডিলিট “আনডু” সম্ভব করে। অ্যাডমিনরা ভুল করে বন্ধ হওয়া একটি টিকিট পুনরুদ্ধার করতে পারে, আর্কাইভ করা একটি প্রোডাক্ট ফিরিয়ে আনতে পারে, বা মিথ্যা স্প্যাম রিপোর্টের পরে ইউজার-জেনারেটেড কনটেন্ট উদ্ধার করতে পারে। ডেটা শারীরিকভাবে gone হলে এমন রিস্টোর ফ্লো দেওয়া কঠিন।\n\nরিলেশনশিপস আরেকটি বড় কারণ। প্যারেন্ট সারিটি হার্ড ডিলিট করলে ফরেন কী কনস্ট্রেইন্ট ভেঙে যেতে পারে বা রিপোর্টে বিভ্রান্তিকর গ্যাপ পড়তে পারে। সফট ডিলিটে, জয়েনগুলো স্থিতিশীল থাকে এবং ইতিহাসগত টোটালস কনসিস্টেন্ট থাকে (দৈনিক রাজস্ব, পূর্ণ অর্ডার, রেসপন্স টাইম স্ট্যাট)।\n\nসফট ডিলিট বিজনেস রেকর্ডগুলোর জন্য শক্তিশালী ডিফল্ট—সাপোর্ট টিকিট, মেসেজ, অর্ডার, ইনভয়েস, অডিট লগ, অ্যাক্টিভিটি হিস্ট্রি, এবং ব্যবহারকারী প্রোফাইল (অবশেষে চূড়ান্ত মুছার আগে)।\n\nউদাহরণ: একটি সাপোর্ট এজেন্ট একটি অর্ডার নোট “ডিলিট” করে যেখানে ভুল আছে। সফট ডিলিটের সাথে, নোটটি সাধারণ UI-এ অদৃশ্য হয়, কিন্তু অভিযোগের সময় সুপারভাইজাররা এখনও তা পর্যালোচনা করতে পারে, এবং ফাইন্যান্স রিপোর্ট ব্যাখ্যা যোগ্য থাকে।\n\n## কখন হার্ড ডিলিট প্রয়োজন\n\nসফট ডিলিট অনেক অ্যাপের জন্য চমৎকার ডিফল্ট, কিন্তু এমন সময় আছে যখন ডেটা রাখা (গোপনীয়তা এমনকি হিডেন রুপে) ভুল। হার্ড ডিলিট মানে রেকর্ডটি সত্যিই মুছে ফেলা, এবং কখনো কখনো এটি কেবলমাত্র উপায় যা আইনি, নিরাপত্তা বা খরচের কারণে মানানসই।\n\nসবচেয়ে স্পষ্ট ক্ষেত্র হল গোপনীয়তা ও চুক্তিভিত্তিক বাধ্যবাধকতা। যদি কেউ GDPR মুছে ফেলার অধিকার ব্যবহার করে, অথবা আপনার চুক্তি নির্দিষ্ট করে নির্দিষ্ট সময় পরে মুছবে, তাহলে “মার্ক করা” প্রায়ই যথেষ্ট নয়। আপনাকে সারিটি, সম্পর্কিত কপিগুলো এবং যেকোনো সংরক্ষিত শনাক্তকারী মুছে ফেলতে হতে পারে যা ব্যক্তির দিকে ইঙ্গিত করে।\n\nনিরাপত্তাও আরেকটি কারণ। কিছু ডেটা রাখতে ভাল নয়: র র কাঁচা অ্যাক্সেস টোকেন, পাসওয়ার্ড রিসেট কোড, প্রাইভেট কী, একবার ব্যবহারযোগ্য ভেরিফিকেশন কোড, বা এনক্রিপ্ট করা নয় এমন সিক্রেট। ইতিহাসের জন্য এগুলো রাখা বিরলভাবে ঝুঁকির মূল্য।\n\nস্কেল সম্পর্কেও হার্ড ডিলিট যুক্তিযুক্ত হতে পারে। যদি আপনার প্রচুর পুরোনো ইভেন্ট, লগ বা টেলিমেট্রি টেবিল থাকে, সফট ডিলিট ধীরে ধীরে ডাটাবেস বাড়ায় এবং কুয়েরি ধীর করে। পরিকল্পিত purge পলিসি সিস্টেমকে প্রতিক্রিয়াশীল রাখে এবং খরচ পূর্বানুমানযোগ্য করে।\n\nহার্ড ডিলিট সাধারণত টেম্পরারি ডেটার জন্য উপযুক্ত (ক্যাশ, সেশন, ড্রাফট ইমপোর্ট), স্বল্পমেয়াদি সিকিউরিটি আর্টিফ্যাক্ট (রিসেট টোকেন, OTP, ইনভাইট কোড), টেস্ট/ডেমো অ্যাকাউন্ট, এবং বিশাল ইতিহাসগত ডাটাসেট যেখানে শুধুমাত্র অগ্রিগেটেড স্ট্যাটসই দরকার।\n\nএকটি ব্যবহারযোগ্য পন্থা হল “বিজনেস ইতিহাস” আলাদা রাখা “ব্যক্তিগত ডেটা” থেকে। উদাহরণস্বরূপ, অ্যাকাউন্টিংয়ের জন্য ইনভয়েস রাখুন, কিন্তু যেগুলো ব্যক্তিকে শনাক্ত করে সেগুলো অনামাইজ বা হার্ড-ডিলিট করুন।\n\nআপনার দল যদি সফট ডিলিট বনাম হার্ড ডিলিট নিয়ে বিতর্ক করে, একটি সহজ টেস্ট ব্যবহার করুন: যদি ডেটা রাখলে আইনগত বা নিরাপত্তা ঝুঁকি তৈরি হয়, তাহলে হার্ড ডিলিট (অথবা অপরিবর্তনীয় অনামাইজেশন) জয়ী হওয়া উচিত।\n\n## কীভাবে সফট ডিলিট মডেল করবেন যাতে চমক না হয়\n\nএকটি সফট ডিলিট তখনই সবচেয়ে ভাল কাজ করে যখন এটি নীরস এবং পূর্বনির্ধারিত। লক্ষ্য সহজ: রেকর্ড ডাটাবেসে থাকে, কিন্তু অ্যাপের সাধারণ অংশগুলি আচরণ করে যেন এটি নেই।\n\n### একটি delete সিগন্যাল বেছে নিন, এবং এর অর্থ স্পষ্ট করুন\n\nতিনটি সাধারণ প্যাটার্ন দেখা যায়: একটি deleted_at টাইমস্ট্যাম্প, একটি is_deleted ফ্ল্যাগ, বা একটি স্ট্যাটাস enum। অনেক দল deleted_at পছন্দ করে কারণ এটি একই সময়ে দুটি প্রশ্নের উত্তর দেয়: এটা কি ডিলিটেড এবং কখন তা ঘটেছে।\n\nযদি আপনার কাছে ইতিমধ্যেই একাধিক লাইফসাইকেল স্টেট থাকে (active, pending, suspended), একটি স্ট্যাটাস enum টিও কাজ করতে পারে, কিন্তু “deleted” কে আলাদা রাখুন “archived” ও “deactivated” থেকে। এগুলো আলাদা:\n\n- Deleted: সাধারণ তালিকায় দেখা উচিত নয় বা ব্যবহার যোগ্য নয়।\n- Archived: ইতিহাসের জন্য রাখা, কিন্তু “past” ভিউতে দেখা যায়।\n- Deactivated: অস্থায়ীভাবে নিষ্ক্রিয়, প্রায়ই ব্যবহারকারী দ্বারা রিভার্স করা যায়।\n\n### ইউনিক ফিল্ডগুলি আগে থেকেই ম্যানেজ করুন\n\nসফট ডিলিট বনাম হার্ড ডিলিট প্রায়ই ইউনিক ফিল্ড যেমন ইমেল, ইউজারনেম বা অর্ডার নম্বরে আটকে যায়। যদি একজন ব্যবহারকারী “ডিলিট” করে কিন্তু তাদের ইমেল এখনও সংরক্ষিত এবং ইউনিক থাকে, তারা আবার সাইন আপ করতে পারবে না।\n\nদুইটি সাধারণ ফিক্স: ইউনিকনেস কেবল নন-ডিলিটেড সারিগুলোর উপর প্রযোজ্য করুন, অথবা ডিলেটকালে মানটি পুনর্লিখন করুন (উদাহরণস্বরূপ একটি র‌্যান্ডম সাফিক্স যুক্ত করা)। কোনটা বেছে নেবেন তা নির্ভর করে প্রাইভেসি এবং অডিট চাহিদার উপর।\n\n### ফিল্টারিং নিয়মগুলো স্পষ্ট (এবং কনসিস্টেন্ট) করুন\n\nভিন্ন অডিয়েন্স কী দেখতে পাবে তা ঠিক করুন। একটি প্রচলিত নিয়ম হতে পারে: সাধারণ ব্যবহারকারীরা কখনই ডিলিটেড রেকর্ড দেখবে না, সাপোর্ট/অ্যাডমিনরা সেগুলো লেবেলসহ দেখতে পারবে, এবং এক্সপোর্ট/রিপোর্টগুলো কেবল অনুরোধে সেগুলো অন্তর্ভুক্ত করে।\n\n"সবাই মনে রাখে যে ফিল্টার যোগ করতে হবে"-এর উপর ভরসা করবেন না। নিয়মটি এক জায়গায় রাখুন: ভিউ, ডিফলট কুয়েরি, বা আপনার ডেটা অ্যাক্সেস লেয়ারে। AppMaster-এ এমনটি মানে endpoint এবং Business Process-এর মধ্যে ফিল্টার বেক করা যাতে ডিলিটেড সারি দুর্ঘটনাক্রমে নতুন স্ক্রীনে ফিরে না আসে।\n\nসংক্ষিপ্ত একটি অভ্যন্তরীণ নোট (বা স্কিমা কমেন্ট) লিখে রাখুন। ভবিষ্যৎ আপনি কৃতজ্ঞ থাকবেন যখন “deleted”, “archived” এবং “deactivated” একই মিটিং-এ আসে।\n\n## রেফারেন্স অক্ষুণ্ণ রাখা: প্যারেন্ট, চিলড্রেন ও জয়েন\n\nরিলেশনশিপের মাধ্যমে অ্যাপ সবচেয়ে বেশি ভাঙে। একটি রেকর্ড প্রায়ই একা থাকে না: ব্যবহারকারীর অর্ডার আছে, টিকিটে কমেন্ট আছে, প্রজেক্টে ফাইল আছে। সফট ডিলিট বনাম হার্ড ডিলিটের জটিল অংশ হল রেফারেন্সগুলো কনসিস্টেন্ট রাখা, আবারও প্রোডাক্টটিকে “গোন” হিসেবে আচরণ করানো।\n\n### ফরেন কী: উদ্দেশ্য করে ফেলুন কোন ব্যর্থ মোড চান\n\nফরেন কী আপনাকে ভাঙা রেফারেন্স থেকে রক্ষা করে, কিন্তু প্রতিটি অপশনের একটি বিভিন্ন অর্থ আছে:\n\n- RESTRICT: যদি চিলড্রেন থাকে তবে ডিলিট ব্লক করে।\n- SET NULL: ডিলিট অনুমোদন করে, কিন্তু চিলড্রেনকে আলাদা করে দেয়।\n- CASCADE: স্বয়ংক্রিয়ভাবে চিলড্রেন ডিলিট করে।\n- NO ACTION: অনেক ডেটাবেসে RESTRICT-এর মতো, কিন্তু টাইমিং আলাদা হতে পারে।\n\nযদি আপনি সফট ডিলিট ব্যবহার করেন, RESTRICT প্রায়ই সবচেয়ে নিরাপদ ডিফল্ট। আপনি সারি রাখেন, তাই কীগুলো মান্য থাকে, এবং চিলড্রেন কিছুই না দেখার ঝুঁকি থাকে না।\n\n### রিলেশনশিপে সফট ডিলিট: orphan না করে লুকানো\n\nসফট ডিলিট সাধারণত ফরেন কী বদলে দেয় না। পরিবর্তে, আপনি অ্যাপে এবং রিপোর্টগুলোতে ডিলিটেড প্যারেন্টকে ফিল্টার করে রাখেন। যদি একজন কাস্টমার সফট-ডিলিট করা হয়, তাদের ইনভয়েসগুলো এখনও সঠিকভাবে জয়েন করবে, কিন্তু স্ক্রীনগুলো ড্রপডাউন-এ কাস্টমার দেখাবে না।\n\nসংযুক্তি, কমেন্ট এবং অ্যাক্টিভিটি লগের জন্য, সিদ্ধান্ত নিন "ডিলিট" ব্যবহারকারীর দৃষ্টিকোণ থেকে কী মানে। কিছু দল শেল রাখে কিন্তু ঝুঁকিপূর্ণ অংশগুলো সরিয়ে দেয়: যদি প্রাইভেসি প্রয়োজন হয় তবে অ্যাটাচমেন্ট কনটেন্টকে একটি প্লেসহোল্ডারে প্রতিস্থাপন করুন, কমেন্টকে ডিলিটেড ইউজারের থেকে এসেছে বলে মার্ক করুন (অথবা লেখককে অনামাইজ করুন), এবং অ্যাক্টিভিটি লগ অপরিবর্তনীয় রাখুন।\n\nজয়েন ও রিপোর্টিংয়ের জন্য একটি স্পষ্ট নিয়ম দরকার: ডিলিটেড সারি অন্তর্ভুক্ত করা উচিত কী না? অনেক দল দুটি স্ট্যান্ডার্ড কুয়েরি রাখে: একটি "কেবল সক্রিয়" এবং একটি "ডিলিটেড সহ", যাতে সাপোর্ট ও রিপোর্টিং গুরুত্বপূর্ণ ইতিহাস অদৃশ্য না করে।\n\n## ধাপে ধাপে: উভয় ব্যবহার করে একটি ডেটা লাইফসাইকেল ডিজাইন করা\n\nবাস্তব নীতিটি প্রায়ই সফট ডিলিটকে দৈনন্দিন ভুলের জন্য এবং হার্ড ডিলিটকে আইনি বা গোপনীয়তার জন্য রেখে দেয়। যদি আপনি একে কেবল একটি সিদ্ধান্ত মনে করেন (সফট বনাম হার্ড), আপনি মধ্যভাগটি মিস করবেন: ইতিহাস কিছু সময় রাখুন, তারপর যা রাখতে হবে তা purge করুন।\n\n### একটি সহজ ৫-পয়েন্ট পরিকল্পনা\n\nশুরুতে ডেটাকে কয়েকটি বালতিতে ভাগ করুন। “ব্যবহারকারী প্রোফাইল” ডেটা ব্যক্তিগত, “লেনদেন” আর্থিক রেকর্ড, এবং “লগ” সিস্টেম ইতিহাস। প্রতিটি বালতি ভিন্ন নিয়ম প্রয়োজন।\n\nএকটি সংক্ষিপ্ত পরিকল্পনা যা বেশিরভাগ দলেই কাজ করে:\n\n- ডেটা গ্রুপ ও মালিক নির্ধারণ করুন, এবং কাকে ডিলিট অনুমোদন দিতে হবে তা নাম লিখে রাখুন।\n- রিটেনশন ও রিস্টোর নিয়ম সেট করুন।\n- কী অনামাইজ করা হবে তার সিদ্ধান্ত নিন।\n- টাইমড purge ধাপ যোগ করুন (এখানে সফট ডিলিট, পরে হার্ড ডিলিট)।\n- প্রতিটি ডিলিট, রিস্টোর ও পর্জ-ইভেন্টের জন্য এক অডিট এন্ট্রি রাখুন (কে, কখন, কী এবং কেন)।\n\n### একটি দৃশ্যমান উদাহরণ দিয়ে বাস্তব করা\n\nধরুন একজন কাস্টমার তাদের অ্যাকাউন্ট বন্ধ করতে অনুরোধ করে। প্রথমে ব্যবহারকারী রেকর্ড সফট ডিলিট করুন যাতে তারা লগইন না করতে পারে এবং রেফারেন্স ভাঙে না। তারপর এমন ব্যক্তিগত ক্ষেত্রগুলো অনামাইজ করুন যা থাকা উচিত নয় (নাম, ইমেল, ফোন), আর অ-ব্যক্তিগত লেনদেনগত তথ্যগুলো অ্যাকাউন্টিং-এর জন্য রাখুন। অবশেষে, নির্ধারিত purge জব যেগুলো এখনও ব্যক্তিগত তা মুছে দেয় অপেক্ষাকৃত সময় পরে।\n\n## সাধারণ ভুল এবং ফাঁদ যা এড়াতে হবে\n\nদলগুলো বিপদের মধ্যে পড়ে না কারণ তারা ভুল পদ্ধতি বেছে নেয়, বরং কারণ তারা অসমভাবে এটি প্রয়োগ করে। একটি সাধারণ নিদর্শন হচ্ছে কাগজে “সফট ডিলিট বনাম হার্ড ডিলিট” থাকলেও বাস্তবে UI-তে এক জায়গায় লুকানো হয় এবং অন্যান্য জায়গায় ভুলে যাওয়া।\n\nএকটি সহজ ভুল: আপনি UI-তে ডিলিটেড রেকর্ড লুকান, কিন্তু সেগুলো API, CSV এক্সপোর্ট, অ্যাডমিন টুল বা ডেটা সিঙ্ক জব থেকে এখনও দেখা যায়। ব্যবহারকারীরা দ্রুত লক্ষ্য করে যখন একটি “ডিলিটেড” কাস্টমার মেইল লিস্টে বা মোবাইল সার্চ রেজাল্টে আসে।\n\nরিপোর্ট ও সার্চ আরেকটি ফাঁদ। যদি রিপোর্ট কুয়েরিগুলো কনসিস্টেন্টলি ডিলিটেড সারি ফিল্টার না করে, টোটালস পরিবর্তিত হয় এবং ড্যাশবোর্ড অনবিশ্বাস্য হয়ে যায়। সবচেয়ে খারাপ ক্ষেত্রে ব্যাকগ্রাউন্ড জবগুলো ডিলিটেড আইটেমগুলো পুনরায় ইনডেক্স করে বা রি-সেন্ড করে কারণ তারা একই নিয়ম প্রয়োগ করেনি।\n\nহার্ড ডিলিটও কখনও বেশি দূর পর্যন্ত যেতে পারে। একটি একক ক্যাসকেডিং ডিলিট অর্ডার, ইনভয়েস, মেসেজ এবং লগগুলো মুছে দিতে পারে যা আপনি আসলে অডিট ট্রেইলের জন্য প্রয়োজন ছিল। যদি হার্ড ডিলিট আবশ্যক হয়, স্পষ্টভাবে নির্ধারণ করুন কি কিছুকে মুছে ফেলা যাবে এবং কি রাখতে বা অনামাইজ করতে হবে।\n\nসফট ডিলিটে ইউনিক কনস্ট্রেইন্ট সূক্ষ্ম ব্যথা দিতে পারে। যদি একজন ব্যবহারকারী তাদের অ্যাকাউন্ট ডিলিট করে এবং পরে একই ইমেল দিয়ে পুনরায় সাইন-আপ করতে চায়, তখন পুরোনো সারি যদি ইমেল ধরে রাখে সাইন-আপ ব্যর্থ হতে পারে। এ জন্য আগে থেকে পরিকল্পনা করুন।\n\nকমপ্লায়েন্স দল জিজ্ঞেস করবে: আপনি প্রমাণ করতে পারবেন কি যে ডিলিশন ঘটেছে, এবং কখন? “আমরা মনে করি এটা মুছে হয়েছে” অনেক ডেটা রিটেনশন রিভিউ পাস করবে না। একটি ডিলিট টাইমস্ট্যাম্প, কে/কী ট্রিগার করেছে, এবং একটি অপরিবর্তনীয় লগ এন্ট্রি রাখুন।\n\nশিপ করার আগে পুরো সারফেসের স্যানিটি চেক করুন: API, এক্সপোর্ট, সার্চ, রিপোর্ট, এবং ব্যাকগ্রাউন্ড জব। টেবিল-বাই-টেবিল ক্যাসকেডগুলো পর্যালোচনা করুন, এবং নিশ্চিত করুন ব্যবহারকারীরা ইউনিক ডেটা (ইমেল বা ইউজারনেম) পুনরায় তৈরী করতে পারবে যদি সেটা আপনার প্রোডাক্ট প্রমিস হয়।\n\n## শিপের আগে দ্রুত চেকলিস্ট\n\nসফট ডিলিট বনাম হার্ড ডিলিট বেছে নেওয়ার আগে, আপনার অ্যাপের প্রকৃত আচরণ যাচাই করুন, কেবল স্কিমা নয়।\n\n- রিস্টোর নিরাপদ এবং পূর্বানুমানযোগ্য কিনা। যদি একজন অ্যাডমিন "আনডিলিট" করে, তাহলে কি তা সঠিক অবস্থায় ফিরে আসে এবং এমন সংবেদনশীল আইটেমগুলো পুনর্জীবিত হয় না যা থাকা উচিত নয় (যেমন প্রত্যাহার করা অ্যাক্সেস টোকেন)?\n- কুয়েরি ডিফল্টভাবে ডিলিটেড ডেটা লুকায় কি না। নতুন স্ক্রীন, এক্সপোর্ট এবং API-গুলো ভুলক্রমে ডিলিটেড সারি অন্তর্ভুক্ত করা উচিত নয়। এক নিয়ম ঠিক করে সব জায়গায় প্রয়োগ করুন।\n- রেফারেন্স ভাংবে না। ফরেন কী ও জয়েনগুলো orphan রেকর্ড বা অর্ধেক-ভরা স্ক্রীন তৈরি করবে না তা নিশ্চিত করুন।\n- পর্গের একটি সময়সূচী ও মালিক আছে। সফট ডিলিট কেবল প্ল্যানের অর্ধেক। কখন ডেটা স্থায়ীভাবে সরানো হবে, কে চালায়, এবং কি বাদ থাকবে (যেমন চলমান ডিসপিউট) তা নির্ধারণ করুন।\n- ডিলিশন লোগড হয় সংবেদনশীল ক্রিয়ার মত। কে উদ্যোগ নেয়, কখন ঘটেছে, এবং কেন—এসব রেকর্ড করুন।\n\nতারপর প্রাইভেসি পথটি শুরু থেকে শেষ পর্যন্ত টেস্ট করুন। আপনি কি GDPR মুছে ফেলার অনুরোধ পুরো সিস্টেম জুড়ে (কপি, এক্সপোর্ট, সার্চ ইনডেক্স, অ্যানালিটিক্স টেবিল, ইন্টিগ্রেশন) পূরণ করতে পারেন, শুধু মেইন ডাটাবেস নয়?\n\nএকটি বাস্তব উপায় হল স্টেজিং-এ একটি "ব্যবহারকারী ডিলিট" ড্রাই রান করা এবং ডেটা ট্রেইলটি অনুসরণ করা।\n\n## উদাহরণ: বিলিং ইতিহাস রেখে একটি ব্যবহারকারী মুছা\n\nএকজন কাস্টমার লিখে: “আমার অ্যাকাউন্ট মুছে দিন।” আপনার কাছে ইনভয়েস আছে যা অ্যাকাউন্টিং ও চার্জব্যাক চেকের জন্য রাখা বাধ্যতামূলক। এটাই জায়গা যেখানে সফট ডিলিট বনাম হার্ড ডিলিট বাস্তববোধগম্য হয়: আপনি অ্যাক্সেস ও ব্যক্তিগত বিবরণ সরিয়ে দিতে পারেন কিন্তু ব্যবসায়িক রেকর্ড রাখতে পারেন।\n\n“অ্যাকাউন্ট” এবং “বিলিং রেকর্ড” আলাদা রাখুন। অ্যাকাউন্ট লগইন ও পরিচয় সম্পর্কিত। বিলিং রেকর্ড একটি ইতিমধ্যে ঘটানো লেনদেন সম্পর্কিত।\n\nএকটি পরিষ্কার পদ্ধতি:\n\n- ব্যবহারকারী অ্যাকাউন্ট সফট ডিলিট করুন যাতে তারা লগইন না করতে পারে এবং প্রোফাইল স্বাভাবিক ভিউ থেকে অদৃশ্য হয়।\n- ইনভয়েস ও পেমেন্টগুলো সক্রিয় রেকর্ড হিসেবে রাখুন, কিন্তু তাদের ব্যক্তিগত ফিল্ডগুলোকে আর যুক্ত করবেন না।\n- ব্যক্তিগত ডেটা (নাম, ইমেল, ফোন, ঠিকানা) অনামাইজ করুন যেমন "Deleted User" প্লাস একটি অভ্যন্তরীণ অ-চিহ্নিত রেফারেন্স।\n- API টোকেন, পাসওয়ার্ড হ্যাশ, সেশন, রিফ্রেশ টোকেন এবং স্মৃতিযুক্ত ডিভাইসের মতো সংবেদনশীল আইটেমগুলো হার্ড ডিলিট করুন।\n- কেবল সেইগুলোকেই রাখুন যা আপনার কমপ্লায়েন্স ও সাপোর্টের জন্য সত্যিই প্রয়োজন, এবং কেন তা ডকুমেন্ট করুন।\n\nসাপোর্ট টিকিট ও মেসেজ মাঝামাঝি জায়গায় থাকে। যদি মেসেজ কনটেন্টে ব্যক্তিগত ডেটা থাকে, আপনাকে হয় অংশ কাটা লাগতে পারে, সংযুক্তি মুছে ফেলতে হতে পারে, এবং টিকিট শেল (টাইমস্ট্যাম্প, ক্যাটাগরি, রেজোলিউশন) রাখতেই হতে পারে কিয়ালিটি ট্র্যাকিংয়ের জন্য। যদি আপনার প্রোডাক্ট মেসেজ পাঠায় (ইমেইল/এসএমএস ইত্যাদি), আউটবাউন্ড শনাক্তকারীও সরান যাতে ব্যক্তি আর যোগাযোগ না করা হয়।\n\nসাপোর্ট কী দেখতে পায়? সাধারণত ইনভয়েস নম্বর, তারিখ, পরিমাণ, স্ট্যাটাস এবং যে ব্যবহারকারী মুছে গেছে ও কখন তা একটি নোট। তারা যা দেখতে পারে না তা হল যে কোনো ব্যক্তি শনাক্তকারী: লগইন ইমেল, পূর্ণ নাম, ঠিকানা, সংরক্ষিত পেমেন্ট কনটেন্ট, বা সক্রিয় সেশন।\n\n## পরবর্তী ধাপ: নিয়ম নির্ধারণ করুন, তারপর কনসিস্টেন্টলি ইমপ্লিমেন্ট করুন\n\nডিলেশনের সিদ্ধান্তগুলো তখনই স্থায়ী হয় যখন সেগুলো লেখা হয় এবং প্রোডাক্ট জুড়ে একইভাবে প্রয়োগ করা হয়। "সফট ডিলিট বনাম হার্ড ডিলিট"-কে প্রথমে একটি নীতি প্রশ্ন হিসেবে বিবেচনা করুন, কোডিং ট্রিক না।\n\nএকটি সাধারণ ডেটা রিটেনশন পলিসি দিয়ে শুরু করুন যা দলের কেউই পড়ে বুঝতে পারে। এতে বলা উচিত আপনি কি রাখেন, কতদিন রাখেন, এবং কেন রাখেন। “কেন” গুরুত্বপূর্ণ কারণ এটি বলে কোন লক্ষ্য জিতবে যখন দুইটি লক্ষ্য সংঘর্ষে পড়ে (উদাহরণ: সাপোর্ট ইতিহাস বনাম গোপনীয়তা অনুরোধ)।\n\nএকটি ভাল ডিফল্ট প্রায়ই হয়: দৈনন্দিন ব্যবসায়িক রেকর্ডগুলোর জন্য সফট ডিলিট, সংবেদনশীল ডেটা (টোকেন, সিক্রেট) এবং যা রাখা উচিত নয় সেইসবের জন্য হার্ড ডিলিট।\n\nএকবার পলিসি স্পষ্ট হলে, সেই ফ্লোগুলো তৈরি করুন যা তা কার্যকর করে: রিস্টোরের জন্য একটি "ট্র্যাশ" ভিউ, চেকের পরে অবিচল ডিলিটের জন্য একটি "পর্গ কিউ", এবং কে কী এবং কখন করেছে সেটা দেখানোর জন্য একটি অডিট ভিউ। “পর্গ” করা “ডিলিট” করার চেয়ে কঠিন করুন যাতে এটি দুর্ঘটনায় ব্যবহার না হয়।\n\nআপনি যদি এটি AppMaster-এ ইমপ্লিমেন্ট করেন (appmaster.io), Data Designer-এ soft-delete ফিল্ড মডেল করা এবং একটি Business Process-এ delete, restore, purge লজিক কেন্দ্রীকরণ করা সাহায্য করে যাতে একই নিয়ম স্ক্রীন ও API এ একরকম প্রয়োগ হয়।