Soft delete বনাম hard delete: অ্যানালিটিক্স, সাপোর্ট, GDPR-শৈলী ডিলিশন, এবং কোয়েরি জটিলতা নিয়ে বাস্তব ট্রেডঅফগুলো জানুন — এবং নিরাপদ রিস্টোর প্যাটার্নগুলো।

একটি ডিলিট বাটন ডাটাবেসে দুই ধরণের অর্থ জানাতে পারে।
হার্ড ডিলিট হলে রো পুরোপুরি মুছে যায়। এর পরে রেকর্ডটি কেবল ব্যাকআপ, লগ, বা রেপ্লিকা থেকে পুনরুদ্ধার করা যায়। এটা বোঝা সহজ, কিন্তু চিরস্থায়ী।
সফট ডিলিট হলে রোটি রাখা হয় কিন্তু deleted_at বা is_deleted মতো একটি ফিল্ড দিয়ে মুছে ফেলা হিসেবে চিহ্নিত করা হয়। অ্যাপ তারপর এই মার্ক করা রো গুলোকে অদৃশ্য হিসেবে ব্যবহার করে। আপনি সম্পর্কিত তথ্য রাখেন, ইতিহাস সংরক্ষণ করেন, এবং মাঝে মাঝে রেকর্ড পুনরায় সক্রিয় করতে পারেন।
এই সিদ্ধান্ত দৈনন্দিন কাজে মানুষের চেয়ে বেশি প্রভাব ফেলে। এটা নির্ধারণ করে আপনি কীভাবে উত্তর দেবেন: “গত মাসে রাজস্ব কেন কমে গেছে?”, “আমার মুছে ফেলা প্রোজেক্ট ফিরিয়ে আনা যাবে?”, বা “আমরা GDPR ডিলিশন রিকোয়েস্ট পেয়েছি — আমরা কি ব্যক্তিগত ডেটা আসলে মুছছি?” এটি UI-তে "deleted" কী বোঝায় তাও নির্ধারণ করে। ব্যবহারকারীরা প্রায়শই ধরে নেন তারা এটি undo করতে পারবে, যতক্ষণ না পারেন।
একটি প্রায়োগিক নিয়ম:
উদাহরণ: একজন কাস্টমার একটি ওয়ার্কস্পেস মুছে ফেলে পরে বুঝতে পারে সেখানে ইনভয়েস ছিল যা হিসাবের জন্য দরকার। যদি soft delete থাকে, সাপোর্ট সেটি পুনরুদ্ধার করতে পারে (যদি আপনার অ্যাপ নিরাপদে রিস্টোর কেস পরিচালনা করে)। হার্ড ডিলিট হলে ব্যাকআপ, দেরি, বা "সম্ভব নয়"—এমন উত্তরের দিকে যেতে হতে পারে।
কোনোটিই সর্বশ্রেষ্ঠ নয়। সবচেয়ে কম যন্ত্রণা দেয় এমন অপশনটি নির্ভর করে আপনি কী রক্ষা করতে চান: ব্যবহারকারীর বিশ্বাস, রিপোর্টিং সঠিকতা, বা গোপনীয়তা সামঞ্জস্য।
ডিলিশন পছন্দগুলো দ্রুত অ্যানালিটিক্সে দেখা দেয়। যখনই আপনি সক্রিয় ব্যবহারকারী, কনভার্সন, বা রাজস্ব ট্র্যাক শুরু করেন, "deleted" আর সরল স্টেট থাকে না এবং সেটা রিপোর্টিং সিদ্ধান্তে পরিণত হয়।
হার্ড ডিলিট করলে অনেক মেট্রিক ক্লিন দেখায় কারণ মুছা রেকর্ডগুলো কোয়েরি থেকে অদৃশ্য হয়ে যায়। কিন্তু আপনি প্রসঙ্গ হারান: পূর্বের সাবস্ক্রিপশন, পূর্বের টিম সাইজ, বা গত মাসে ফানেল কেমন ছিল ইত্যাদি। একটি মুছে ফেলা কাস্টমার ইতিহাসে চার্ট বদলে দিতে পারে যখন আপনি রিপোর্ট পুনরায় চালান, যা ফাইন্যান্স ও গ্রোথ রিভিউতে ভয় দেখাতে পারে।
সফট ডিলিট করলে ইতিহাস থাকলেও ভুল করে সংখ্যাগুলো বাড়িয়ে ফেলতে পারেন। একটি সাধারণ "COUNT users"-এ চলে যেতে পারে এমন লোকগুলোও থাকতে পারে যারা চলে গেছে। একটি churn চার্ট ডাবল কাউন্ট করেও ফেলতে পারে যদি এক রিপোর্টে deleted_at-কে churn ধরা হয় এবং অন্যটিতে উপেক্ষা করা হয়। এমনকি রাজস্বও ঝামেলায় পড়তে পারে যদি ইনভয়েস থাকে কিন্তু অ্যাকাউন্টকে deleted হিসেবে চিহ্ন করা হয়।
কী কাজ করে তা হলো একটি কনসিস্টেন্ট রিপোর্টিং প্যাটার্ন বেছে নেওয়া এবং সেটাতে স্থির থাকা:
চাবি হলো ডকুমেন্টেশন যাতে এনালিস্টদের অনুমান করতে না হয়। লিখে রাখুন “active” মানে কি, soft-deleted ইউজাররা কি অন্তর্ভুক্ত হয়, এবং যদি একটি অ্যাকাউন্ট পরে ডিলিট হয় তবে রাজস্ব কিভাবে অ্যাট্রিবিউট করা হবে।
কংক্রিট উদাহরণ: একটি ওয়ার্কস্পেস ভুল করে মুছে ফেলা হয়, পরে পুনরুদ্ধার করা হয়। যদি আপনার ড্যাশবোর্ড ফিল্টার না করে ওয়ার্কস্পেসগুলো গুণে, আপনি একটি হঠাৎ পতন এবং পুনরুদ্ধার দেখাবেন যা বাস্তব ব্যবহার না করে ঘটেনি। স্ন্যাপশট থাকলে ইতিহাস স্থিতিশীল থাকে যখন প্রোডাক্ট ভিউগুলো এখনও মুছে ফেলা ওয়ার্কস্পেসগুলো লুকায়।
ডিলিশন সংক্রান্ত অধিকাংশ সাপোর্ট টিকিট একই রকম শোনায়: “আমি ভুল করে মুছে ফেলেছি,” বা “আমার রেকর্ড কোথায় গেল?” আপনার ডিলিট কৌশল নির্ধারণ করে সাপোর্ট কয় মিনিটে উত্তর দিতে পারবে, না হলে সঠিক উত্তর হবে “এটা চলে গেছে।”
সফট ডিলিট থাকলে সাধারণত আপনি কি ঘটেছে যাচাই করে undo করতে পারেন। হার্ড ডিলিট হলে সাপোর্ট প্রায়শই ব্যাকআপের ওপর নির্ভর করতে হবে (যদি থাকে), এবং সেটা ধীর, অসম্পূর্ণ, বা একক আইটেমের জন্য অসম্ভব হতে পারে। এজন্য সিদ্ধান্ত কেবল ডাটাবেস ডিটেইল নয়—এটা নির্ধারণ করে আপনার প্রোডাক্ট সমস্যা হওয়ার পর কতটা "সাহায্যযোগ্য"।
যদি আপনি বাস্তব সাপোর্ট আশা করেন, কয়েকটি ক্ষেত্র যোগ করুন যা ডিলিশন ইভেন্ট ব্যাখ্যা করে:
deleted_at (টাইমস্ট্যাম্প)deleted_by (ইউজার আইডি বা সিস্টেম)delete_reason (ঐচ্ছিক, সংক্ষিপ্ত লেখা)deleted_from_ip বা deleted_from_device (ঐচ্ছিক)restored_at এবং restored_by (যদি আপনি রিস্টোর সমর্থন করেন)পুরো অ্যাক্টিভিটি লগ না থাকলেও, এই তথ্যগুলো সাপোর্টকে বলতে দেয়: কে এটা মুছেছে, কখন, এবং এটা কি দুর্ঘটনা নাকি অটোমেটেড ক্লিনআপ।
হার্ড ডিলিট সাময়িক ডেটার জন্য ঠিক আছে, কিন্তু ইউজার-ফেসিং রেকর্ডের জন্য সেটা সাপোর্টের কার্যকলাপকে বদলে দেয়।
সাপোর্ট একক রেকর্ড রিস্টোর করতে পারবে না যদি আপনি অন্য কোথাও রিসাইকেল বিন না করে থাকেন। তাদের হয়ত সম্পূর্ণ ব্যাকআপ রিস্টোর করতে হবে, যা অন্যান্য ডেটাকে প্রভাবিত করতে পারে। তারা সহজে প্রমাণও দিতে পারবে না যে কি ঘটেছে, ফলে দীর্ঘ অনুসন্ধান হতে পারে।
রিস্টোর ফিচার কাজের ধরণও বদলে দেয়। যদি ব্যবহারকারী নিজে নির্দিষ্ট সময়ের মধ্যে স্বয়ংক্রিয়ভাবে রিস্টোর করতে পারে, টিকিট পড়া কমে। যদি রিস্টোর সাপোর্টের ম্যানুয়াল কাজ দরকার করে, টিকিট বাড়তে পারে, কিন্তু তা দ্রুত এবং পুনরাবৃত্তিমূলক হবে, এক-অফ তদন্তের পরিবর্তে।
“মুছে ফেলার অধিকার” সাধারণত মানে আপনি ব্যক্তির ডেটা প্রক্রিয়াকরণ বন্ধ করবেন এবং এমন জায়গা থেকে ডেটা মুছে ফেলবেন যেখানে সেটা ব্যবহারযোগ্য। এটি সবসময় অর্থ নয় যে আপনাকে প্রতিটি ঐতিহাসিক অ্যাগ্রিগেট একেবারেই মুছে ফেলতে হবে, কিন্তু এর মানে হলো আপনি আর আইনি কারণে ডেটা রাখার অপরিহার্য কারণ না থাকলে ব্যক্তিগতভাবে শনাক্তযোগ্য ডেটা "যাস্ট ইন কেস" রেখে রাখা উচিত নয়।
এইখানে সফট বনাম হার্ড ডিলিট প্রোডাক্ট পছন্দের বাইরে চলে যায়। একটি সফট ডিলিট (যেমন deleted_at সেট করা) সাধারণত কেবল অ্যাপ থেকে রেকর্ড লুকায়। ডেটা ডাটাবেসে থাকে, অ্যাডমিনরা এখনও কোয়েরি করতে পারে, এবং প্রায়শই এক্সপোর্ট, সার্চ ইনডেক্স, এবং অ্যানালিটিক্স টেবিলেও থাকে। অনেক GDPR ডিলিশন অনুরোধে সেটা মুছে ফেলা নয়।
আপনাকে তখনও purge করতে হবে যখন:
ব্যাকআপ এবং লগ হলো টিমগুলো যে অংশটি ভুলে যায়। একটি এনক্রিপ্টেড ব্যাকআপ থেকে একটি সিংগেল রো মুছে ফেলা নাও যেতে পারে, কিন্তু আপনি নিয়ম রাখতে পারেন: ব্যাকআপ দ্রুত মেয়াদোত্তীর্ণ হবে, এবং রিস্টোর করা ব্যাকআপগুলো সিস্টেম লাইভ করার আগে ডিলিশন ইভেন্টগুলো পুনরায় প্রয়োগ করতে হবে। লগগুলো কচকে কাঁচা ব্যক্তিগত ডেটা সংরক্ষণ করা এড়িয়ে চলুক এবং স্পষ্ট রিটেনশন সীমা থাকুক।
একটি সহজ, ব্যবহারিক নীতি হল দুই-ধাপ ডিলিট:
যদি আপনার প্ল্যাটফর্ম source code export বা data export সাপোর্ট করে, তাহলে এক্সপোর্ট করা ফাইলগুলোকে ডাটাস্টোর হিসেবেই বিবেচনা করুন: কোথায় তারা থাকে, কে অ্যাক্সেস করতে পারে, এবং কখন সেগুলো মুছে যাবে তা নির্ধারণ করুন।
সফট ডিলিট শুনতে সহজ মনে হয়: একটি deleted_at (বা is_deleted) ফ্ল্যাগ যোগ করুন এবং রো লুকিয়ে রাখুন। লুকানো খরচ হলো আপনার যে স্থানে ডেটা পড়েন সেগুলো এখন সেই ফ্ল্যাগ মনে রাখবে। একবার ভুল করে ফেললে আপনি পেয়েছেন অদ্ভুত বাগ: টোটালসে মুছে ফেলা আইটেম থাকে, সার্চে “ঘোস্ট” ফলাফল দেখা যায়, অথবা ব্যবহারকারী কিছু দেখতে পায় যা তারা ভাবছিল মুছে গেছে।
UI ও UX এর এজ কেসগুলো দ্রুত সামনে আসে। ধরুন একটি টিম একটি প্রকল্প "Roadmap" মুছে দেয় এবং পরে কেউ নতুন "Roadmap" বানাতে চায়। যদি ডাটাবেসে নামের উপর ইউনিক নিয়ম থাকে, নতুন ক্রিয়েট ব্যর্থ হতে পারে কারণ মুছে ফেলা রোটি এখনও আছে। সার্চও বিভ্রান্ত করতে পারে: আপনি তালিকায় মুছে ফেলা আইটেম লুকান কিন্তু গ্লোবাল সার্চে না হলে ব্যবহারকারীরা মনে করবে অ্যাপ ভাঙা।
সফট ডিলিট ফিল্টার সাধারণত মিস হয় নিচের জায়গাগুলোতে:
পারফরম্যান্স প্রথমে সাধারণত ঠিক থাকে, কিন্তু অতিরিক্ত কন্ডিশন কাজ বাড়ায়। যদি বেশিরভাগ রো অ্যাক্টিভ হয়, deleted_at IS NULL ফিল্টার সস্তা। যদি অনেক রো deleted থাকে, ডাটাবেসকে আরও রো স্কিপ করতে হবে যদি না আপনি উপযুক্ত ইনডেক্স যোগ করেন। সহজ কথায়: এটা এমন যেন আপনি বর্তমান ডকুমেন্ট খুঁজছেন এমন একটি ড্রয়ারে অনেক পুরানো ডকুমেন্টও থাকা।
একটি আলাদা “আর্কাইভ” এলাকা বিভ্রান্তি কমাতে পারে। ডিফল্ট ভিউটি কেবল সক্রিয় রেকর্ড দেখাক এবং মুছে ফেলা আইটেমগুলোকে এক জায়গায় স্পষ্ট লেবেল ও টাইম উইন্ডোর সাথে রাখুন। দ্রুত তৈরি করা টুলগুলোতে (যেমন Koder.ai-তে তৈরি অভ্যন্তরীণ অ্যাপ) এই প্রোডাক্ট সিদ্ধান্ত প্রায়শই যেকোনো চালাক কোয়েরি ট্রিকের চেয়ে বেশি সাপোর্ট টিকিট কমায়।
সফট ডিলিট একটি ফিচার নয়, এটা একটি ডেটা মডেল পছন্দ, এবং আপনি যেটা বেছে নেবেন তা সবকিছুকে প্রভাবিত করবে: কোয়েরি নিয়ম, রিস্টোর আচরণ, এবং "deleted" আপনার প্রোডাক্টে কী বোঝায়।
deleted_at এবং deleted_byসবচেয়ে সাধারণ প্যাটার্ন হলো nullable টাইমস্ট্যাম্প। রেকর্ড মুছে দিলে deleted_at (এবং সাধারণত deleted_by—ইউজার আইডি) সেট করা হয়। "Active" রেকর্ডগুলো হলো যেগুলোর deleted_at null।
এটা তখন ভালো কাজ করে যখন আপনাকে পরিষ্কার রিস্টোর দরকার: রিস্টোর মানে deleted_at এবং deleted_by ক্লিয়ার করা। এটা সাপোর্টকে একটি সহজ অডিট সিগন্যাল দেয়।
কিছু টিম status ফিল্ড ব্যবহার করে যেখানে states আছে active, archived, এবং deleted। যখন "archived" একটা প্রকৃত প্রোডাক্ট স্টেট (অনেক স্ক্রিন থেকে লুকানো কিন্তু বিলিংয়ে কাউন্ট করা) তখন এটা সাহায্য করে।
খরচ হলো নিয়মগুলো: আপনাকে প্রতিটি স্থানে প্রতিটি স্টেটের মান ঠিকভাবে সংজ্ঞায়িত করতে হবে: সার্চ, নোটিফিকেশন, এক্সপোর্ট, অ্যানালিটিক্স—সবখানে।
সংবেদনশীল বা উচ্চ-মূল্যবান অবজেক্টের জন্য আপনি মুছে ফেলা রো গুলো আলাদা টেবিলে স্থানান্তর করতে পারেন, বা একটি অ্যাপেন্ড-ওনলি লগে ইভেন্ট রেকর্ড করতে পারেন।
deleted_at, deleted_bystatusএটি প্রায়শই ব্যবহৃত হয় যখন রিস্টোর কড়া নিয়ন্ত্রণে থাকতে হবে, বা আপনি চান অডিট ট্রেইল কিন্তু ডেইলি কোয়েরিজে মিক্সড ডিলিটেড ডেটা দেখতে না পাওয়া।
চাইল্ড রেকর্ডগুলোর জন্যও একটি স্পষ্ট নিয়ম থাকা দরকার। যদি একটি ওয়ার্কস্পেস মুছে ফেলা হয়, প্রজেক্ট, ফাইল, এবং মেম্বারশিপগুলো কি হবে?
archived করা (মুছে ফেলা নয়)প্রতিটি সম্পর্কের জন্য একটি নিয়ম বেছে নিন, লিখে রাখুন, এবং ধারাবাহিক রাখুন। বেশিরভাগ "রিস্টোর ভুল হয়ে যায়" বাগ আসে প্যরেন্ট ও চাইল্ড রেকর্ডগুলোতে বিভিন্ন ডিলিট অর্থ ব্যবহারের কারণে।
একটি রিস্টোর বাটন সহজ শোনালেও এটি অনুমতিগুলো ভাঙতে পারে, পুরনো ডেটা ভুল জায়গায় উদ্ধার করতে পারে, বা ব্যবহারকারীদের বিভ্রান্ত করতে পারে যদি "রিস্টোর" তাদের প্রত্যাশা মতো না ঘটে। শুরু করুন আপনার প্রোডাক্ট কোন সুনির্দিষ্ট প্রতিশ্রুতি দেবে সেটা লিখে।
একটি ছোট, কড়াকড়ি সিকোয়েন্স ব্যবহার করুন যাতে রিস্টোর পূর্বানুমানযোগ্য এবং অডিটযোগ্য হয়।
আপনি যদি দ্রুত অ্যাপ বানান Koder.ai-র মত একটি টুলে, এই চেকগুলো জেনারেটেড ওয়ার্কফ্লো অংশ করে রাখুন যাতে প্রতিটি স্ক্রীন এবং এন্ডপয়েন্ট একই নিয়ম অনুসরণ করে।
সফট ডিলিটের সবচেয়ে বড় ব্যথা ডিলিট নিজেই নয়, বরং সেই সব জায়গাগুলো যেখানে রেকর্ড "চলে গেছে" মনে করে ভুলে যাওয়া হয়। অনেক টীম নিরাপত্তার জন্য সফট ডিলিট বেছে নেয়, তারপর ভুল করে deleted আইটেমগুলো সার্চ রেজাল্ট, ব্যাজ, বা টোটালসে দেখিয়েই দেয়। ব্যবহারকারীরা দ্রুত লক্ষ্য করে যখন একটি ড্যাশবোর্ড বলে "12 প্রোজেক্ট" কিন্তু তালিকায় কেবল 11 দেখায়।
দ্বিতীয়টি হলো অ্যাক্সেস কন্ট্রোল। যদি একটি ইউজার, টিম, বা ওয়ার্কস্পেস সফট-ডিলিট করা হয়, তাদের লগইন, API কল, বা নোটিফিকেশন পাওয়ার অধিকার থাকা উচিত না। এটি প্রায়শই ছাড়া যায় যখন লগইন চেক শুধু ইমেইল দেখে এবং ডিলিট ফ্ল্যাগ চেক করে না।
পরের সাধারণ ফাঁদ যা পরে সাপোর্ট টিকিট তৈরি করে:
ইউনিকনেস কোলিশন গুলো বিশেষত খারাপ যখন রিস্টোর হয়। কেউ যদি নতুন অ্যাকাউন্ট তৈরি করে একই ইমেইল দিয়ে যখন পুরনোটি সফট-ডিলিট করা আছে, তখন রিস্টোর ব্যর্থ হবে বা ভুল আইডেন্টিটি ওভাররাইট করতে পারে। আগে থেকেই নীতি ঠিক করে নিন: purge পর্যন্ত পুনঃব্যবহার ব্লক করুন, পুনঃব্যবহার অনুমতি দিন কিন্তু রিস্টোর নিষিদ্ধ করুন, বা রিস্টোর হলে নতুন আইডেন্টিফায়ারে ফিরিয়ে আনুন।
একটি সাধারণ দৃশ্য: একটি সাপোর্ট এজেন্ট সফট-ডিলিট করা ওয়ার্কস্পেস রিস্টোর করে। ওয়ার্কস্পেস ফিরে আসে, কিন্তু তার মেম্বাররা ডিলিটেড থাকেন, এবং একটি ইন্টিগ্রেশন পুরোনো রেকর্ডগুলোকে পার্টনার টুলে পুনরায় সিঙ্ক করে। ব্যবহারকারীর দৃষ্টিতে রিস্টোর "আধা কাজ করা" এবং নতুন ঝামেলা তৈরি করে।
রিস্টোর শিপ করার আগে এই আচরণগুলো স্পষ্ট করে রাখুন:
একটি B2B SaaS টিমের "Delete workspace" বাটন আছে। এক শুক্রবার, একজন অ্যাডমিন ক্লিনআপ চালায় এবং 40টি ওয়ার্কস্পেস মুছে দেয় যা ইনটিভ দেখালো। সোমবার, তিনটি কাস্টমার বললো তাদের প্রোজেক্টগুলো চলে গেছে এবং তাত্ক্ষণিক রিস্টোর চাইছে।
টিমটা মনে করেছিল সিদ্ধান্ত সহজ হবে। তা ছিল না।
প্রথম সমস্যা: যদি ওয়ার্কস্পেস রো হার্ড-ডিলিট হয়ে যায় এবং ক্যাসকেডে প্রোজেক্ট, ফাইল, মেম্বারশিপও মুছে যায়, সাপোর্ট কিছুই রিস্টোর করতে পারবে না; করা যায় শুধুমাত্র ব্যাকআপ থেকে। যার মানে সময়, ঝুঁকি, এবং কাস্টমারের কাছে অপ্রিয় উত্তর।
দ্বিতীয় সমস্যা: অ্যানালিটিক্স খারাপ দেখায়। ড্যাশবোর্ডটি "active workspaces" গণনা করে কেবল সেখানে যেখানে deleted_at IS NULL আছে। ভুল ডিলিট চার্টে হঠাৎ পতন দেখায় এবং সাপ্তাহিক রিপোর্ট তুলনা করে মিথ্যা churn স্পাইক ফ্ল্যাগ করে। ডেটা চলে যায়নি, কিন্তু ভুল জায়গায় বাদ পড়েছে।
তৃতীয় সমস্যা: একটি গোপনীয়তা অনুরোধ আসে প্রভাবিত এক ইউজারের জন্য। তারা তাদের ব্যক্তিগত ডেটা মুছে দিতে বলে। একটি কেবল সফট ডিলিট তা পূরণ করে না। টিমকে ব্যক্তিগত ক্ষেত্রগুলো (নাম, ইমেইল, IP লগ) purge করার পরিকল্পনা করতে হবে যখন অবশ্যক।
চতুর্থ সমস্যা: সবাই জিজ্ঞেস করে, "কে ডিলিট চাপলো?" যদি কোনো ট্রেইল না থাকে, সাপোর্ট কী বলবে?
একটি নিরাপদ প্যাটার্ন হলো ডিলিটকে একটি ইভেন্ট হিসেবে ট্রিট করা এবং স্পষ্ট মেটাডেটা রাখা:
deleted_by, deleted_at, এবং একটি রিজন বা টিকিট আইডি রেকর্ড করুনএটাই সেই ধরনের ওয়ার্কফ্লো যা টিমগুলো সাধারণত Koder.ai-র মত প্ল্যাটফর্মে দ্রুত তৈরি করে, পরে বুঝতে পারে ডিলিট নীতিও ঠিক ততটা ডিজাইনিং চাই যতটা ফিচার।
সফট ডিলিট বনাম হার্ড ডিলিট বাছাই করা প্রেফারেন্সের চেয়ে বেশি—এটা নির্ভর করে আপনার অ্যাপ রেকর্ড “গোন” হওয়ার পর কি নিশ্চয়তা দিতে হবে। লেখার আগে এই প্রশ্নগুলো করুন।
একটি সহজ উপায় সিদ্ধান্ত যাচাই করার: একটি বাস্তব ইনসিডেন্ট বেছে নিয়ে তা ধাপে ধাপে চালিয়ে দেখুন। উদাহরণ: কেউ শুক্রবার রাতে ভুলে একটি ওয়ার্কস্পেস মুছে দিল। সোমবার সাপোর্টকে ডিলিশন ইভেন্ট দেখতে হবে, নিরাপদে রিস্টোর করতে হবে, এবং সংশ্লিষ্ট ডেটা পুনরুদ্ধার করে এমন কিছু পুনরুজ্জীবিত করা থেকে বিরত থাকতে হবে যা রাখা উচিৎ নয়। যদি আপনি Koder.ai-র মত প্ল্যাটফর্মে অ্যাপ বানাচ্ছেন, তখন এই নিয়মগুলো আগে থেকে নির্ধারণ করুন যাতে জেনারেটেড ব্যাকএন্ড ও UI এক নীতিতে চলে, বদলে কয়েকটি স্পেশাল কেস ছড়িয়ে না পড়ে কোডে।
একটি সহজ নীতি লিখে টীম এবং সাপোর্টের সঙ্গে শেয়ার করে শুরু করুন। যদি তা লিখে না রাখেন, তা ভেসে যাবে এবং ব্যবহারকারীরা অসামঞ্জস্য অনুভব করবে।
একটি সাধারণ নিয়ম সেট দিয়ে শুরু করুন:
তারপর দুইটি স্পষ্ট পথ তৈরি করুন যা কখনো মিশবে না: একটি “অ্যাডমিন রিস্টোর” পথ ভুলের জন্য, এবং একটি “প্রাইভেসি purge” পথ আসল ডিলিশনের জন্য। রিস্টোর পথ উল্টে ফেরা যোগ্য এবং লগ করা হওয়া উচিত। purge পথ চিরস্থায়ী হওয়া উচিত এবং সমস্ত সম্পর্কিত ব্যক্তিগত ডেটা মুছে বা অ্যানোনিমাইজ করা উচিত, যদি আপনার নীতি সেটি দাবি করে, ব্যাকআপ বা এক্সপোর্টসহ।
গার্ডরেইল যোগ করুন যাতে মুছে ফেলা ডেটা প্রোডাক্টে আবার লিক না করে আসে। সবচেয়ে সহজ উপায় হলো "deleted" কে আপনার টেস্টে একটি প্রথম-শ্রেণির স্টেট ধরে রাখা। নতুন কোয়েরি, লিস্ট পেজ, সার্চ, এক্সপোর্ট, এবং অ্যানালিটিক্স জবের জন্য রিভিউ পয়েন্ট যোগ করুন। একটি ভাল নিয়ম হলো: যদি একটি স্ক্রীন ব্যবহারকারী-ফেসিং ডেটা দেখায়, তাহলে সেটাকে deleted রেকর্ড সম্পর্কে একটি স্পষ্ট সিদ্ধান্ত থাকতে হবে (লুকান, লেবেল দেখান, অথবা শুধুমাত্র অ্যাডমিন-র জন্য)।
আপনি যদি প্রোডাক্টের শুরুর দিকে থাকেন, স্কিমা লক করার আগে উভয় ফ্লো প্রোটোটাইপ করুন। Koder.ai-তে আপনি পরিকল্পনা মোডে ডিলিশন পলিসি স্কেচ করতে পারেন, বেসিক CRUD জেনারেট করতে পারেন, এবং দ্রুত রিস্টোর ও purge সিনারিওগুলো চেষ্টা করে দেখুন, তারপর স্কিমা চূড়ান্ত করুন।