লজিক্যাল রিপ্লিকেশন বনাম ব্যাচ ETL: সিঙ্ক স্টাইল বাছাই

আমরা "ডেটা সিঙ্ক" করে কী সমস্যা সমাধান করছি?\n\nদলগুলো ডেটা এক জায়গায় থাকে না বলেই সিস্টেমগুলোর মধ্যে কপি করে। Sales হয়তো CRM‑এ থাকে, পেমেন্টগুলো বিলিং টুলে, এবং operations‑এর ডেটা একটি অভ্যন্তরীণ ড্যাশবোর্ডে। Support‑এর কর্মীরা ভিন্ন ভিন্ন টুলে ঝাঁপিয়ে পড়া ছাড়া পুরো চিত্র দেখতে চান না, আর লীডাররা চাইতে চান রিপোর্টগুলো বাস্তব ঘটনাগুলোর সাথে মেলে।\n\n"বিশ্বস্ত সিঙ্ক" বর্ণনা করতে সহজ, বজায় রাখতে কঠিন: সঠিক রেকর্ডগুলো পৌঁছায়, কিছু গুরুত্বপূর্ণ মিস হয় না, এবং আপডেটগুলো যথেষ্ট দ্রুত আসে যাতে কাজে লাগে। "যথেষ্ট দ্রুত" কাজের উপর নির্ভর করে। Fraud চেকের জন্য কয়েক মিনিট লাগতে পারে; মাসিক ফাইন্যান্স রিপোর্ট ঘণ্টা বরদাশত করতে পারে।\n\nযখন সিঙ্ক ভাঙে, সাধারণত দেখতে পাওয়া যায় মিসিং রেকর্ড, ডুপ্লিকেট, স্টেল ফিল্ড, বা আংশিক আপডেট (উদাহরণ: অর্ডার হেডার আসে কিন্তু লাইন আইটেম আসে না)।\n\nএকটি সহজ মন্টাল মডেল হলো ইভেন্ট বনাম স্ন্যাপশট।\n\nইভেন্টগুলো আলাদা আলাদা পরিবর্তন: “Order #1842 তৈরি করা হয়েছে,” “স্ট্যাটাস পরিবর্তন হয়ে shipped হয়েছে,” “refund জারি করা হয়েছে।” change‑data পদ্ধতিগুলো সাধারণত ইভেন্টগুলো সরায় এবং নিকট-রিয়েল-টাইম আচরণ সমর্থন করতে পারে।\n\nস্ন্যাপশটগুলো নির্ধারিত সময়ে কপি: “প্রতি রাতে গতকালের অর্ডার কপি করো।” ব্যাচ ETL প্রায়শই এইভাবে কাজ করে। এটি সহজ হতে পারে, কিন্তু ডেটা ততটা ফ্রেশ হয় না।\n\nলজিক্যাল রিপ্লিকেশন বনাম ব্যাচ ETL সম্পর্কে বেশিরভাগ যুক্তি আসলে এই সিদ্ধান্ত সম্পর্কে: আপনাকে অবিচ্ছিন্ন ইভেন্টগুলো দরকার নাকি পর্যায়ক্রমিক স্ন্যাপশটই যথেষ্ট?\n\n## লজিক্যাল রিপ্লিকেশন এবং ব্যাচ ETL — সহজভাবে ব্যাখ্যা\n\nলজিক্যাল রিপ্লিকেশন মানে উৎস ডাটাবেস পরিবর্তনগুলো ঘটার সাথে সাথে একটি স্ট্রিম পাঠায়। পুরো টেবিল কপি করার বদলে এটি প্রকাশ করে “রো যোগ করা হয়েছে,” “রো আপডেট হয়েছে,” বা “রো মুছে ফেলা হয়েছে।” গন্তব্য সেই পরিবর্তনগুলো ক্রমানুসারে প্রয়োগ করে, তাই উৎসের সাথে ভালোভাবে মিলাখায়।\n\nব্যাচ ETL মানে আপনি নির্ধারিত সময় পর স্ন্যাপশট নেন। একটি জব ডেটা এক্সট্র্যাক্ট করে (প্রায়ই “শেষ রান থেকে সবকিছু”), প্রয়োজনে ট্রান্সফর্ম করে, এবং গন্তব্যে লোড করে। যদি রিপ্লিকেশন লাইভ আপডেটের মতো লাগে, ব্যাচ ETL যেন প্রতি ঘণ্টা (বা প্রতি রাত) চেক করে ধরে নেওয়া।\n\nতারা সাধারণত বিভিন্ন স্থানে চলে। রিপ্লিকেশন ডাটাবেইসের চেইঞ্জ লগ‑এর কাছে থাকে এবং অবিরত চালায়। ব্যাচ ETL সাধারণত একটি নির্ধারিত জব যা চলে, বন্ধ করে, পুনরায় চলে।\n\nযাই হোক, আপনাকে একই বিশ্বাসযোগ্যতার প্রশ্নের উত্তর দিতে হবে:\n\n- ডিলিটগুলো কিভাবে উপস্থাপিত হবে যাতে গন্তব্যে “ভূত” সারি না থাকে?\n- যদি একই পরিবর্তন দুবার আসে তাহলে কী হবে (idempotency)?\n- অনেক সারি দ্রুত পরিবর্তিত হলে অর্ডারিং কীভাবে ঠিক রাখা হবে?\n- রিস্টার্ট বা রিডেপ্লয়ের সময়ে পরিবর্তনগুলি মিস না হওয়ার জন্য কী করবেন?\n\nউদাহরণ: একটি অর্ডার তৈরি হয়, তারপর স্ট্যাটাস “pending” থেকে “paid” হয়, তারপর refunded হয়। রিপ্লিকেশন তিনটি চেঞ্জ ইভেন্ট পাঠায়। একটি দৈনিক স্ন্যাপশট কেবল চূড়ান্ত স্ট্যাটাসই ধরতে পারে যদি না আপনি ব্যাচ প্রসেসটি মধ্যবর্তী স্টেটগুলো জোগাড় রাখার মতো ডিজাইন করেন।\n\n## ফ্রেশনেস ও লেটেন্সি: রিয়েল‑টাইম‑এর কতটা কাছে লাগবে?\n\nরিপ্লিকেশন এবং ব্যাচ ETL তুলনা করার আগে ব্যবসায়িক ভাষায় “যতটা ফ্রেশ দরকার” ঠিক করুন। একটি সংখ্যা দিয়ে শুরু করুন: “support 5 মিনিট পর্যন্ত পুরোনো ডেটা নিয়ে কাজ করতে পারে,” অথবা “finance গতকালের টোটালেই ঠিক আছে।”\n\nFreshness মানে যখন কেউ ডেটা ব্যবহার করে তখন ডেটার বয়স। Latency মানে উৎসে পরিবর্তন হলে গন্তব্যে সেই পরিবর্তন দেখা দেওয়ার বিলম্ব। আপনি গড় ল্যাটেন্সি কম থাকতে পারেন কিন্তু যদি সিঙ্ক বারবার আটকে পড়ে তাহলে ডেটা তবুও পুরোনো হতে পারে।\n\n### লেটেন্সি কোথা থেকে আসে\n\nসহজ একটি সিঙ্কও অনেক ধরণের বিলম্ব জুড়ে দেয়: ক্যাপচার (আপনি যখন পরিবর্তন লক্ষ্য করেন), ট্রানজিট (ডেটা পাঠানো), প্রসেসিং (ট্রান্সফর্ম ও ডিডুপিং), এবং অ্যাপ্লাই (গন্তব্যে লেখা ও ইনডেক্সিং)।\n\nএক সচল ট্রিকল (রিপ্লিকেশন বা ঘন মাইক্রো‑ব্যাচ) মসৃণ ফ্রেশনেস দেয়, কিন্তু আপনাকে সারাদিন সিঙ্ক চালাতে হয়। নির্ধারিত ব্যাচগুলো বুঝতে সহজ, কিন্তু সেগুলো স্পাইক তৈরি করে: রাত ২টায় ভারী লোড, তারপর পরবর্তী রান পর্যন্ত ডেটা স্টেল।\n\nনিকট‑রিয়েল‑টাইম দরকার যখন মানুষ দ্রুত সিদ্ধান্ত নেয় বা কাস্টমার ফলাফল তাত্ক্ষণিক দেখে। Support‑এর ড্যাশবোর্ডে নতুন অর্ডার দ্রুত দেখানো উচিত যাতে এজেন্ট কোনো জিনিস আউট‑অফ‑স্টক বলে না দেয়। অন্যদিকে, যদি প্রধান ব্যবহার হয় সাপ্তাহিক রিপোর্ট বা মাসিক ইনভয়েসিং, সবাইকে তাত্ক্ষণিক আপডেট পাঠানো অতিরিক্ত জটিলতা বাড়ায় কিন্তু ফলাফল উন্নত করে না।\n\nপ্র্যাকটিক্যাল উপায় সিদ্ধান্ত নেওয়ার:\n\n- সিঙ্ক করা ডেটা কে ব্যবহার করে, এবং তারা কী সিদ্ধান্ত নেয়?\n- যদি ডেটা 15 মিনিট পুরোনো হয় তাহলে কী ভেঙে যাবে?\n- অবিরত চালাতে খরচ কত (ইনফ্রা ও অন‑কল সময়)?\n- গন্তব্য কখন সবচেয়ে কম ব্যস্ত?\n- আপনি কী ফ্রেশনেস অঙ্গীকার করবেন (এবং সেটি কিভাবে জানাবেন)?\n\n## ফেইলিওর রিকভারি: কিছু ভাঙলে সঠিক অবস্থায় ফেরানো\n\nসিঙ্কগুলি সাধারণত নাটকীয়ভাবে ভাঙে না। সেগুলো ছোট, বিরক্তিকরভাবে ভাঙে: সার্ভার রিস্টার্ট হয়, নেটওয়ার্ক হিকআপ কানেকশন ড্রপ করে, বা একটি জব লোডের মাঝেই ক্র্যাশ করে। লক্ষ্য “কখনো ব্যর্থ না হওয়া” নয়—লক্ষ্য হলো “সঠিক শেষ অবস্থা পুনরুদ্ধার করা।”\n\nসাধারণ ফেইলিওর মোডের মধ্যে সোর্স আউটেজ, গন্তব্য আউটেজ, প্রসেসিংয়ে জব ক্র্যাশ, বা কনস্ট্রেন্ট ভাঙানো ব্যাড ডেটা আছে।\n\nলজিক্যাল রিপ্লিকেশনে, পুনরুদ্ধার সাধারণত সংরক্ষিত অবস্থান (প্রায়শই লগ অফসেট) থেকে চেঞ্জগুলো পুনরায় প্লে করা। যদি গন্তব্য ডাউন থাকে, পরিবর্তনগুলো কিউ হয় যতক্ষণ না এটি ফিরে আসে, তারপর সেগুলো ক্রমানুসারে চালু হয়। এটি পরিষ্কার যদি আপনি রিপ্লিকেশন স্লট (বা সমতুল্য) পরিচালনা করেন যাতে দীর্ঘ আউটেজে এটি অসীম না बढ़ে।\n\nব্যাচ ETL‑এ, পুনরুদ্ধার সাধারণত একটি সময় উইন্ডো পুনরায় চালানো—উদাহরণ: “গতকাল পুনরায় লোড কর” বা “গত ২ ঘণ্টা পুনরায় লোড কর।” অপারেশনের দিক থেকে এটি সহজ, কিন্তু আপনার লোড লজিককে দ্বি‑চলন নিরাপদ (safe to run twice) রাখতে হবে।\n\nসবচেয়ে বড় বিশ্বাসভঙ্গকারী সমস্যাটি আংশিক লিখন। একটি ক্র্যাশ ব্যাচের 70% লেখার পর হলে ডুপ্লিকেট বা মিসিং রো থাকতে পারে যদি আপনি আগে থেকেই পরিকল্পনা করেন না। দুই ধরণের প্যাটার্ন দুই শৈলীতেই সাহায্য করে:\n\n- লোডগুলো idempotent করুন যাতে একই ইনপুট দুইবার প্রয়োগ করলে শেষ অবস্থা একই হয়।\n- স্থিতিশীল প্রাইমারি কী দিয়ে upsert প্রাধান্য দিন।\n- সফল কমিটের পরে শুধু “last processed” মার্কার এগোন।\n- প্রত্যাখ্যাত সারিগুলো কোথাও রাখুন যাতে পরিদর্শন ও আবার চালানো যায়।\n\nব্যাকফিল (ইতিহাস পুনরায় প্রক্রিয়া) এ যন্ত্রণা প্রকাশ পায়। ব্যাচ ETL প্রায়শই জেতে যখন আপনাকে এক মাসের ডেটা পুনরায় প্রক্রিয়া করতে হয় কারণ পুনরায় চালানোই ডিজাইনের অংশ। রিপ্লিকেশনও ব্যাকফিল করতে পারে, কিন্তু সাধারণত তা আলাদা পথ (প্রথমে স্ন্যাপশট, তারপর চেঞ্জ প্রয়োগ) হওয়ায় প্রয়োজনের আগে টেস্ট করা ভাল।\n\nউদাহরণ: যদি অর্ডার সিঙ্ক লাইন আইটেম লিখে ফেললেও হেডার লেখার আগে ক্র্যাশ করে, তাহলে প্রতিটি অর্ডারের (বা প্রতিটি ব্যাচের) জন্য এক ট্রানজ্যাকশনে upsert‑ভিত্তিক লোড করলে অর্ধ‑সিঙ্ক হওয়া অর্ডার রয়ে যাবে না।\n\n## স্কিমা বিবর্তন: ডেটা মডেল বদলে গেলে কী হয়?\n\nস্কিমা পরিবর্তন সেই জায়গা যেখানে অনেক সিঙ্ক গোপনে বিশ্বাস হারায়। পাইপলাইন চলতে থাকতে পারে যখন ডেটার মান খোলসের নিচে ধীরে ধীরে বদলাচ্ছে। রিপ্লিকেশন ডাটাবেস স্তরে ভেঙে যেতে পারে, আর ETL প্রায়শই ট্রান্সফর্ম ও রিপোর্টে পরে ভেঙে যায়।\n\nঅ্যাডিটিভ পরিবর্তন সবচেয়ে সহজ: নতুন কলাম, নতুন টেবিল, নতুন অপশনাল ফিল্ড। সাধারণত কাজ করে যদি গ্রাহকরা এগুলোকে “অতিরিক্ত” হিসেবে ধরে নেয় এবং ডিফল্ট মান যুক্তিযুক্ত। ধাঁধা হলো প্রত্যাশা করা যে প্রতিটি ডাউনস্ট্রিম কনজিউমার নতুন ফিল্ড লক্ষ্য করবে বা কিভাবে ব্যাকফিল করতে হবে জানবে।\n\nব্রেকিং পরিবর্তন ঝুঁকিপূর্ণ: রিনেম, টাইপ পরিবর্তন, কলাম ডিলেট, বা একটি মানের অর্থ বদলানো। এগুলো দ্রুত ব্যর্থ করতে পারে (জব এরর) বা ধীরে ধীরে ব্যর্থ হতে পারে (ডেটা এসে যায় কিন্তু ভুল)।\n\n### নিরাপদভাবে বিবর্তন কিভাবে করবেন\n\nপরিবর্তন সমন্বয়ের জন্য যথেষ্ট সময় রাখুন:\n\n- স্কিমা বা পে-লোড ভার্সন করুন (v1, v2) যাতে পুরনো এবং নতুন একই সাথে থাকতে পারে।\n- একটি সামঞ্জস্যতা সময় চালান যেখানে পুরাতন এবং নতুন ফিল্ড দুটোই থাকে।\n- নতুন শেপে নির্ভর করা লজিক চালু করার আগে ব্যাকফিল করুন।\n- নিশ্চিত না হওয়া পর্যন্ত ফিল্ডগুলি মুছে ফেলবেন না।\n\n### ম্যাপিং কোথায় ভেঙে যায়\n\nবেশি বাস্তব ভাঙা ঘটে সিস্টেমগুলোর মধ্যে গ্লু অংশে। উদাহরণ: আপনার ETL orders কে customers‑এর সাথে customer_id দিয়ে জয়েন করে। যদি তা client_id‑এ রিনেম হয়, জয়েনটি সব‑নাল ম্যাচে পরিণত হতে পারে এবং এখনও সারি তৈরি করে।\n\nনজর রাখুন দুর্বল জায়গাগুলির ওপর: টাইপ কাস্ট, এমন জয়েন যা ধরে নেয় কীগুলা বদলাবে না, এবং ডাউনস্ট্রিম নিয়ম যেমন “status নির্দিষ্ট এই মানগুলোর মধ্যে হতে হবে।”\n\n## নিরাপত্তা ও মালিকানা: কে কী সিঙ্ক করার অনুমতি পাবে?\n\nনিরাপত্তার প্রশ্ন দুটো পদ্ধতিতেই একই রকম দেখায়, কিন্তু ঝুঁকি ভিন্ন জায়গায় উঠে আসে। রিপ্লিকেশন সাধারণত অবিরতভাবে চালায় এবং চেঞ্জগুলোর ব্যাপক রিড অ্যাক্সেস থাকে। ব্যাচ ETL নির্ধারিত সময়ে বড় অংশ ডেটা টেনে আনতে পারে। উভয় ক্ষেত্রে, এমন সর্বনিম্ন অনুমতি দিন যা সিঙ্কের কাজ চালাতে যথেষ্ট।\n\nএকটি ডেডিকেটেড সার্ভিস অ্যাকাউন্ট ব্যবহার করুন, ব্যক্তিগত লগইনের পরিবর্তে। শুধু প্রয়োজনীয় টেবিল, কলাম বা ভিউগুলিতে রিড‑ওনলি অ্যাক্সেস দিন, এবং কোথা থেকে কানেক্ট করা যাবে তা সীমাবদ্ধ করুন। সম্ভব হলে একটি ডেডিকেটেড “sync view” প্রকাশ করুন যা এমন ডেটা আগে থেকেই ফিল্টার করে যেটা গন্তব্য কখনো দেখবে না।\n\nসংবেদনশীল ফিল্ডগুলো টীমকে বিস্মিত করে। গন্তব্যকে রেকর্ডের প্রয়োজন থাকতে পারে, কিন্তু সব কিছু নয়। সিদ্ধান্ত নিন শুরুতেই কোনগুলো বাদ দেওয়া, মাস্ক করা, বা টোকেনাইজ করা হবে—ব্যক্তিগত কন্ট্যাক্ট ডিটেইল, পেমেন্ট তথ্য, বা অভ্যন্তরীণ নোট ইত্যাদি। ট্রানজিটের সময় ডেটা এনক্রিপ্ট করুন, এবং গোপনগুলি পাইপলাইন কনফিগে রাখবেন না—সেগুলো একটি সঠিক সিক্রেট স্টোরে রাখুন।\n\nমালিকানা পরে অনন্তকাল বিতর্ক ঠেকায়:\n\n- প্রতিটি ফিল্ডের (শুধু টেবিল নয়) একটি সত্যির উৎস বাছুন।\n- সিদ্ধান্ত নিন গন্তব্যে লেখার অনুমতি আছে কি না।\n- কনফ্লিক্ট কিভাবে হ্যান্ডেল হবে সিদ্ধান্ত নিন (last write wins, target edits ignore, manual review)।\n- গন্তব্যে কপি করা ডেটার retention নিয়ম সেট করুন।\n\nঅডিট হচ্ছে বিশ্বাসের শেষ টুকরো। আপনি জানতে চাইবেন: কে ডেটা অ্যাক্সেস করেছে, কী পরিবর্তন হয়েছে, এবং কখন তা ল্যান্ড করেছে। একটি সোজা অনুশীলন হলো ট্রেসযোগ্য sync run id এবং টাইমস্ট্যাম্প বহন করা যাতে আপডেট end‑to‑end ট্র্যাক করা যায়।\n\n## সিঙ্ককে বিশ্বাসযোগ্য রাখার জন্য কী মনিটর করবেন\n\nএকটি সিঙ্ক তখনই কার্যকর যদি আপনি মঙ্গলবার কোনো অপ্রত্যাশিত দিনে সেটি বিশ্বাস করতে পারেন। পদ্ধতির যে কোনো ধরনের হোক, মনিটরিং বলতে হবে: আপনি কতটা পিছিয়ে আছেন, কতবার ব্যর্থ হচ্ছে, এবং সংখ্যাগুলো এখনও যুক্তিযুক্ত কিনা।\n\nতিনটি দৈনিক হেলথ সিগন্যাল:\n\n- Lag/latency: গন্তব্য উৎসের থেকে কতটা পিছিয়ে আছে\n- Error rate: ব্যর্থতা, রিট্রাই, এবং ডেড‑লেটার বা “failed rows”‑এ পাঠানো রেকর্ড\n- Throughput: প্রতি মিনিটে প্রসেস হওয়া সারি বা ইভেন্ট, এবং হঠাৎ করে near‑zero এ নামা\n\nতারপর কিছু ডেটা কোয়ালিটি চেক যোগ করুন যা নীরব সমস্যা ধরবে। কিছু গুরুত্বপূর্ণ টেবিল বাছুন (orders, invoices, tickets) এবং সেগুলোকে নিয়মিতভাবে ভ্যালিডেট করুন। যদি গতকাল সোর্সে 1,240 অর্ডার ছিল, গন্তব্যে 1,180 থাকলে অবশ্যই কারন জানুন।\n\nসাধারণ কভার করা চেকগুলো:\n\n- দিন অনুযায়ী (অথবা ক্রিটিক্যাল ফিডের জন্য ঘণ্টা) সারি গণনা\n- মিল থাকা উচিত এমন টোটাল (পরিমাণের যোগ, paid অর্ডারের সংখ্যা)\n- প্রয়োজনীয় ফিল্ডে null‑রেট (email, status, timestamps)\n- কী‑এর ইউনিকনেস (কোনও ডুপ্লিকেট order_id নেই)\n- “ডিলেট সত্য”: ক্যানসেল বা ডিলিট হওয়া রেকর্ডও downstream‑এ মুছছে বা মার্ক করা হচ্ছে\n\nConsistency সমস্যাগুলো প্রায়ই গ্যাপে লুকায়: দেরিতে আসা আপডেট, মিসিং ডিলিট, বা আউট‑অব‑অর্ডারে অ্যাপ্লাই হওয়া ইভেন্ট। সবথেকে পুরানো unprocessed টাইমস্ট্যাম্প ট্র্যাক করুন, এবং মাঝে মাঝে র‍্যান্ডম স্যাম্পল করে নিশ্চিত করুন সাম্প্রতিক সংস্করণটি আছে কিনা।\n\nঅ্যালার্টিং‑এ, এটিকে সোজা এবং কার্যকর রাখুন। থ্রেশহোল্ড সেট করুন (উদাহরণ: lag 15 মিনিটের বেশি, error rate 1% এর বেশি, throughput baseline‑এর নিচে 10 মিনিট) এবং একটি রানবুক রাখুন যা বলে: প্রথমে কী চেক করবেন, কিভাবে নিরাপদে রেপ্লে করবেন, এবং কিভাবে নিশ্চিত করবেন সব সঠিক হয়েছে।\n\n## ধাপে ধাপে: সঠিক সিঙ্ক পদ্ধতি কিভাবে বাছবেন\n\nডেটা কে ব্যবহার করবে তা স্পষ্ট করুন। একটি ফাইন্যান্স রিপোর্ট, একটি সাপোর্ট ড্যাশবোর্ড, এবং একটি অটোমেটেড প্রাইসিং রুল সব একই টেবিল ব্যবহার করলেও আলাদা ব্যবহারে ভিন্ন চাহিদা থাকে। যদি সিদ্ধান্ত সময়‑সংবেদনশীল হয়, দেরিতে আসা ডেটা কেবল বিরক্তিকর নয়—ভুল হতে পারে।\n\nএকটি সহজ সিদ্ধান্ত প্রক্রিয়া:\n\n1. Name the consumers and their decisions. List the screens, reports, and processes that depend on the sync and what they affect.\n2. Set targets, not vibes. Agree on freshness (seconds, minutes, hours), correctness (what errors are acceptable), and cost (infrastructure, engineering time, operational burden).\n3. Pick the simplest pattern that meets the targets. Use replication when you need near real time and predictable change capture. Use micro-batches when “every few minutes” is fine. Use nightly batch for reporting and historical snapshots. Hybrid is common.\n4. Plan recovery. Decide how far back you can replay, how you’ll run a backfill, and how loads stay idempotent.\n5. Define trust checks and ownership. Choose the validations that prove health (counts, totals, last-updated time, spot checks) and name who gets paged and who fixes data.\n\nকনক্রিট উদাহরণ: যদি support‑কে গ্রাহকের সাথে কথোপকথন করে অর্ডারের স্ট্যাটাস জানতেই হয়, মিনিটগুলো গুরুত্বপূর্ণ, তাই রিপ্লিকেশন বা মাইক্রো‑ব্যাচ উপযুক্ত। যদি finance‑কে দৈনিক রাজস্ব সংখ্যা দরকার, রাতে একবারের ব্যাচ সাধারণত যথেষ্ট।\n\n## সাধারণ ভুলগুলো যা সিঙ্ককে অবিশ্বাস্য করে তোলে\n\nসবচেয়ে বড় ফাঁদ হলো ধরে নেওয়া যে “ফ্রেশ” ডেটা স্বয়ংক্রিয়ভাবে “সঠিক” ডেটা। একটি পাইপলাইন সেকেন্ড‑এর মধ্যে পিছনে থাকতে পারে এবং তবু ভুল হতে পারে কারণ একটা জয়েন বদলে গেছে, একটি ফিল্টার যোগ হয়েছে, বা একটি সারি ডুপ্লিকেট হয়েছে। ভ্যালিডেশন বাদ দিলে আপনি প্রায়ই তখনই লক্ষ্য করবেন যখন ড্যাশবোর্ড অদ্ভুত দেখায় বা গ্রাহক অভিযোগ করে।\n\nডিলিট আরেকটি সাধারণ মিস। রিপ্লিকেশন এবং ETL উভয়কেই “কীভাবে মুছবেন” সেই পরিকল্পনা দরকার। যদি System A রেকর্ড হার্ড‑ডিলিট করে কিন্তু System B কেবল ইনসার্ট ও আপডেট করে, রিপোর্ট সময়ের সাথে বিচ্যুত হবে। সফট‑ডিলিটও ঝুঁকিপূর্ণ হতে পারে যদি সিঙ্ক ডিলিট ফ্ল্যাগ ও টাইমস্ট্যাম্প বহন না করে।\n\nবারবার দেখা ভুলগুলো:\n\n- ফ্রেশনেসকে প্রধান লক্ষ্য ধরে রেখে মৌলিক কাউন্ট, টোটাল, এবং স্পট চেক বাদ দেওয়া\n- ইনসার্ট ও আপডেট সিঙ্ক করা, কিন্তু ডিলিট, মার্জ, বা নিষ্ক্রিয় স্টেটগুলো না নেওয়া\n- ফিল্ড ম্যাপিং হার্ড‑কোড করা যা কলাম রিনেম, ভাগ হওয়া, বা টাইপ পরিবর্তনে চুপচাপ ভেঙে যায়\n- যখন ঐতিহাসিক ডেটা ঠিক করতে হবে তখন কোনো ব্যাকফিল পরিকল্পনা না থাকা\n- কেবল জব ফেইলিওরের ওপর অ্যালার্ট করা, lag, মিসিং ডেটা, বা ধীর ড্রিফট‑এর ওপর নয়\n\nউদাহরণ: আপনার CRM একজন গ্রাহককে “inactive” হিসেবে চিহ্নিত করে বাট ডিলিট করে না। আপনার ETL কেবল সেই গ্রাহকদের কপি করে যাদের status = active। এক মাস পরে, রেভেনিউ রিপোর্ট ঠিক থাকলেও রিটেনশন মেট্রিক অতিরঞ্জিত দেখায় কারণ inactive গ্রাহকরা কখনো সিঙ্ক হয়নি (বা মোছা হয়নি)। সবকিছু ফ্রেশ দেখছিল, কিন্তু সঠিকতা ইতিমধ্যে ভুলে গেছে।\n\n## "ডান হয়েছে" বলার আগে দ্রুত চেকলিস্ট\n\nসংখ্যায়, স্পষ্ট মালিকানা, ও প্রমাণিত পুনরুদ্ধার নিয়ে ‘ডান’ হওয়া নিয়ে একমত হন। প্রথম দিনে ঠিক দেখা সিঙ্ক বাস্তব পরিবর্তন ও ব্যর্থতার সাথে ধীরে ধীরে বিচ্যুত হতে পারে।\n\n- Freshness promise লিখে রাখুন। লক্ষ্য বিলম্ব, কখন তা মাপবেন, এবং মিস করলে কী হবে তা নির্ধারণ করুন।\n- Source of truth স্পষ্ট করুন। গুরুত্বপূর্ণ ফিল্ডগুলোর (status, price, customer email) জন্য কোন সিস্টেম বিজয়ী তা ডকুমেন্ট করুন এবং আপডেট এক‑ওয়ে না দুই‑ওয়ে তা নির্ধারণ করুন।\n- Recovery end‑to‑end টেস্ট করা আছে। একটি ব্যর্থতা সিমুলেট করুন এবং নিশ্চিত করুন আপনি রেপ্লে বা রিরান করে ডুপ্লিকেট বা মিসিং সারি ছাড়াই ফিরিয়ে আনতে পারেন।\n- Schema change নিয়ম আছে। সিদ্ধান্ত নিন কে পরিবর্তন অনুমোদন করবে, কীভাবে রোল আউট হবে, এবং রিনেম, টাইপ পরিবর্তন, ড্রপ করা কলাম কিভাবে হ্যান্ডেল করবেন।\n- Monitoring কার্যকর। Lag, error rate, এবং মূল ডেটা চেকগুলো ট্র্যাক করুন, এমন অ্যালার্ট সহ যা অন‑কল ব্যক্তিকে পরবর্তী করণীয় বলে দেয়।\n\nরিয়েলিটি চেক: যদি delivery_instructions অর্ডারে যোগ করা হয়, আপনার প্রক্রিয়াটি স্পষ্ট করে বলবে যে এটি স্বয়ংক্রিয়ভাবে সিঙ্ক হচ্ছে, জোরে ব্যর্থ করছে, বা নিরাপদে উপেক্ষা করা হচ্ছে।\n\n## বাস্তবসম্মত উদাহরণ: দুই সিস্টেমের মধ্যে অর্ডার সিঙ্ক করা\n\nএকটি কোম্পানির কল্পনা করুন যার অর্ডার PostgreSQL‑এ সংরক্ষিত। দুটো টীম সেই ডেটা চায়: Support লাইভ ড্যাশবোর্ড চায় “আমার অর্ডার কোথায়?” জানতে, এবং Finance‑কে স্থিতিশীল দৈনিক সংখ্যা দরকার রিপোর্টের জন্য।\n\nতারা সবকিছুকে এক জায়গায় বাঁধার চেষ্টা না করে একটি মিক্সড অ্যাপ্রোচ নেয়।\n\nSupport‑এর জন্য তারা লজিক্যাল রিপ্লিকেশন ব্যবহার করে যাতে নতুন অর্ডার এবং স্ট্যাটাস আপডেট দ্রুত একটি রিড‑অপটিমাইজড ডাটাবেসে আসে যা ড্যাশবোর্ড চালায়। Finance‑এর জন্য তারা ব্যবসার সময়ের পরে একবার দৈনিক ব্যাচ ETL চালায়। এটি ফাইনালাইজড অর্ডারগুলো রিপোর্টিং ওয়্যারহাউসে লোড করে, ব্যবসায়িক নিয়ম (ট্যাক্স, ডিসকাউন্ট, রিফান্ড) প্রয়োগ করে, এবং একটি দৈনিক স্ন্যাপশট তৈরি করে যা তাদের পায়ের নিচে স্থির থাকে।\n\nএরপর একটি স্কিমা পরিবর্তন ঘটে: প্রোডাক্ট টিম refund_reason যোগ করে। Support তা অবিলম্বে চায়। রিপ্লিকেশন নতুন কলাম দ্রুত পাঠাতে পারে, আর ব্যাচ জব প্রথমে এটিকে অপশনাল হিসেবে ধরে নিতে পারে (ডিফল্ট “unknown”) যতক্ষণ না রিপোর্টিং লজিক প্রস্তুত।\n\nএকদিন Support গন্তব্য 3 ঘণ্টা ডাউন থাকে। ফিরে আসার পরে রিপ্লিকেশন সংরক্ষিত অবস্থান থেকে ক্যাচ আপ করে। মূল ধাপ শুধু “এটি পুনরায় চালু হয়েছে” নয়, বরং “এটি সঠিক”: তারা আউটেজ উইন্ডোর জন্য অর্ডার কাউন্ট যাচাই করে এবং সাম্পল‑চেক করে সাম্প্রতিক কয়েকটি অর্ডার end‑to‑end পরীক্ষা করে।\n\nপ্রতিটি সকালে তারা স্থিতি বিশ্বাস করার জন্য কয়েকটা সিগন্যাল চেক করে: রিপ্লিকেশন ল্যাগ, সোর্স বনাম গন্তব্য অর্ডার কাউন্ট গত 24 ঘণ্টার জন্য, ফাইন্যান্স টেবিলগুলিতে ডুপ্লিকেট আছে কি না, ব্যাচ সফল হয়েছে এবং প্রতিটি রান‑এ কত সারি লোড হয়েছে, এবং উভয় সিস্টেমে উচ্চ-মুল্যের কয়েকটি অর্ডারের নমুনা যাচাই।\n\n## পরবর্তী ধাপ: সিঙ্ককে দৃশ্যমান ও পরিচাল্যযোগ্য করুন\n\nআপনি একটি পদ্ধতি (অথবা হাইব্রিড) বেছে নিলেন—এখন প্রকৃত কাজ হলো সিঙ্ককে প্রতিদিন মানুষ যাতে বিশ্বাস করে তা নিশ্চিত করা। একটি পরিমাপযোগ্য লক্ষ্য বেছে নিন এবং এটিকে একটি প্রোডাক্ট মেট্রিকের মতো পরিণত করুন। বেশিরভাগ টিমের প্রথম লক্ষ্য হয় ফ্রেশনেস (ডেটা কতটা নতুন) অথবা নির্ভুলতা (কতটা ভুল)।\n\nছোট থেকে শুরু করুন: একটি টেবিল, একটি ইভেন্ট স্ট্রিম, অথবা একটি গুরুত্বপূর্ণ ওয়ার্কফ্লো (যেমন অর্ডার বা টিকিট)। সেই পাথটি স্থিতিশীল করুন, তারপর প্যাটার্ন কপি করুন। দ্রুত সম্প্রসারণ করার আগে যদি আপনি সমস্যা সনাক্ত ও সংশোধন করতে না পারেন, তবে পরিস্থিতি দ্রুত বড় ঝামেলা তৈরি করে।\n\nঅ-টেকনিক্যাল দলের জন্য একটি প্র্যাকটিক্যাল “sync status” ভিউতে সাধারণত থাকে: বর্তমান ল্যাগ বনাম লক্ষ্য, শেষ সফল সিঙ্ক সময়, শেষ ব্যর্থ প্রচেষ্টা, আজ প্রক্রিয়াকৃত ভলিউম বনাম প্রত্যাশিত রেঞ্জ, এবং স্ট্যাটাস লাল হলে কী করতে হবে সে সম্পর্কে এক সংক্ষিপ্ত নোট।\n\nIf you want to build internal admin screens like this quickly, a no-code platform such as AppMaster (appmaster.io) can help you ship a monitoring view and adjust it as requirements change, without rewriting everything when the schema or workflow evolves.\n\n