ইঞ্জিনিয়াররা ফিনটেক সিস্টেমের জন্য একটি ফিল্ড গাইড পান

Fintech Engineering Handbook অর্থকে কেন্দ্র করে সফটওয়্যার নির্মাণকারী ইঞ্জিনিয়ারদের জন্য ব্যবহারিক কিছু প্যাটার্ন তুলে ধরে, যেখানে লেজার ডিজাইন ও আইডেমপোটেন্সি থেকে শুরু করে ওয়েবহুক, রিকনসিলিয়েশন, অ্যাক্সেস কন্ট্রোল, এবং প্রোডাকশন টেস্টিং পর্যন্ত সবই অন্তর্ভুক্ত।

এই হ্যান্ডবুকটি সেই ইঞ্জিনিয়ারদের জন্য, যারা অন্য সফটওয়্যার ক্ষেত্র থেকে ফিনটেকে আসেন। একটি সোশ্যাল অ্যাপ ডুপ্লিকেট নোটিফিকেশন থেকে ঘুরে দাঁড়াতে পারে। কিন্তু একটি মনি সিস্টেম ডুপ্লিকেট উইথড্রয়াল, ভুলভাবে রাউন্ড হয়ে যাওয়া ফি, বা অনুপস্থিত সেটেলমেন্ট রেকর্ডকে হালকাভাবে নিতে পারে না। গাইডটি এই কাজকে তিনটি নিয়মের চারপাশে সাজায়: ডেটা বানিয়ে ফেলো না, ডেটা হারিও না, এবং যাচাই ছাড়া বাহ্যিক বা অভ্যন্তরীণ সিস্টেমকে বিশ্বাস করো না।

প্রথম পাঠ শুরু হয় রিপ্রেজেন্টেশন দিয়ে। অর্থের জন্য একটি পরিমাণ এবং একটি কারেন্সি দরকার, এবং কাজের জন্য যথেষ্ট সূক্ষ্মতাসহ তা সংরক্ষণ করতে হয়। হ্যান্ডবুকটি আর্থিক অঙ্কের জন্য ফ্লোটিং-পয়েন্ট টাইপ ব্যবহার না করার সতর্কতা দেয়, কারণ সাধারণ পার্সার ও রানটাইম এমনকি অন্যথায় যত্নসহকারে তৈরি সিস্টেমের কিনারায় রাউন্ডিং ত্রুটি আনতে পারে। এটি টিমগুলোকে স্থির ক্ষুদ্র একক, ইচ্ছামতো নির্ভুল দশমিক, র‍্যাশনাল নাম্বার, অথবা এগুলোর মিশ্রণ ব্যবহারের দিকে নির্দেশ করে, সিস্টেমটি ব্যালান্স সংরক্ষণ করছে, রেট গণনা করছে, নাকি ক্রিপ্টো অ্যাসেট হ্যান্ডেল করছে তার ওপর নির্ভর করে।

এই পার্থক্যটি গুরুত্বপূর্ণ। একটি $12.34 fiat ব্যালান্স ISO 4217-এর কারেন্সি মেটাডেটার অধীনে 1,234 সেন্ট হিসেবে মানিয়ে যেতে পারে। একটি ক্রিপ্টো টোকেনে 18 দশমিক থাকতে পারে এবং তা 64-বিট পূর্ণসংখ্যা অতিক্রম করতে পারে। একটি সাধারণ JSON সংখ্যা সাবধানী অভ্যন্তরীণ ডিজাইন নষ্ট করে দিতে পারে যদি কোনো ক্লায়েন্ট এটিকে IEEE 754 ডাবল হিসেবে পার্স করে। হ্যান্ডবুকটি ইঞ্জিনিয়ারদের অর্থ স্ট্রিং বা ক্ষুদ্রতম-এককের পূর্ণসংখ্যা হিসেবে পাঠাতে উৎসাহিত করে।

গাইডটি রাউন্ডিংকে একটি ব্যবসায়িক সিদ্ধান্ত হিসেবে দেখে, ফরম্যাটিংয়ের বিষয় হিসেবে নয়। ফি হিসাব, কারেন্সি রূপান্তর, সুদ, এবং রেট প্রয়োগ - সবই এমন ভগ্নাংশ তৈরি করতে পারে যা সিস্টেমকে বণ্টন করতে হবে। টিমগুলোর ঠিক করতে হবে অবশিষ্টাংশ কে পাবে বা হারাবে, রেসিডুয়াল রেকর্ড করতে হবে, এবং পERSISTENCE বা display-এর মতো কোনো সীমানা না আসা পর্যন্ত রাউন্ডিং এড়াতে হবে। যদি কোনো প্ল্যাটফর্ম একটি পেমেন্টকে একাধিক ভাগে বিভক্ত করে, তবে রাউন্ড করা অংশগুলো আর মূল অঙ্কের সঙ্গে ঠিকমতো যোগ নাও হতে পারে। হ্যান্ডবুকটি সেই ফাঁকটি লুকানোর বদলে ট্র্যাক করতে বলে।

লেজার-সংক্রান্ত অংশটি হ্যান্ডবুকের কেন্দ্রবিন্দু। গাইডটি ডাবল-এন্ট্রি বুককিপিংকে একটি ইঞ্জিনিয়ারিং প্যাটার্ন হিসেবে ব্যাখ্যা করে: প্রতিটি মুভমেন্টে একটি অ্যাকাউন্টে ক্রেডিট এবং অন্যটিতে ডেবিট হয়, ফলে অর্থের একটি উৎস এবং গন্তব্য থাকে। বাহ্যিক প্রোভাইডারদেরও অ্যাকাউন্ট থাকে। ইউজার ব্যালান্স mutable balance field-এর বদলে posting থেকে আসে। সংশোধন ঘটে নতুন linked entry-এর মাধ্যমে, posted record edit করে নয়।

এই পদ্ধতি অডিটরদের জন্য একটি trail দেয়। একটি আর্থিক সিস্টেমকে ব্যাখ্যা করতে পারতে হবে কী ঘটেছে, কে তা ট্রিগার করেছে, সিস্টেম কখন তা book করেছে, কেন তা ঘটেছে, এবং সিদ্ধান্তকে সমর্থন করেছে কোন source data। হ্যান্ডবুকটি value time, booking time, এবং settlement time আলাদা করে, কারণ এই তারিখগুলো ভিন্ন ভিন্ন প্রশ্নের উত্তর দেয়। একটি card transaction সোমবার ঘটতে পারে, মঙ্গলবার কোম্পানির সিস্টেমে ঢুকতে পারে, এবং শুক্রবার bank-এ settle হতে পারে। এই তারিখগুলোকে একটিমাত্র created_at ফিল্ডে মিশিয়ে দিলে এমন তথ্য হারিয়ে যায় যা পরে টিম আর পুনর্গঠন করতে পারবে না।

হ্যান্ডবুকটি event sourcing-কেও সতর্কতার সঙ্গে দেখে। Event sourcing টিমকে শক্তিশালী audit trail দিতে পারে, কারণ event log derived state-এর source হয়ে যায়। গাইডটি এটিকে সার্বজনীন উত্তর হিসেবে বিক্রি করে না। ইঞ্জিনিয়ারদের এখনও projections, snapshots, schema evolution, এবং বহু বছর ধরে টিকে থাকা পুরোনো event-এর জন্য tools দরকার। অনেক পার্শ্ববর্তী ডোমেইনে, হ্যান্ডবুকটি বলে, একটি নির্ভরযোগ্য change log-সহ প্রচলিত model কম operational cost-এ কাজের চাহিদা মেটাতে পারে।

Execution pattern-ও গাইডের আরেকটি বড় অংশ জুড়ে আছে। Fintech systemগুলো নকশাগতভাবেই call retry করে বলে idempotency বিশেষ গুরুত্ব পায়। একটি withdrawal request প্রোভাইডার পেয়ে যাওয়ার পর timeout হতে পারে। ক্লায়েন্ট আবার চেষ্টা করতে পারে। সার্ভারকে এই সব delivery-কে একটিমাত্র effect-এ একত্র করতে হবে। হ্যান্ডবুকটি স্পষ্ট idempotency key পছন্দ করে, যা client এবং operation-এর scope-এ সীমাবদ্ধ, পাশাপাশি atomic barrier, যা একই সময়ে আসা দুইটি duplicate request সামলাতে পারে।

Funds reservation আরেক ধরনের race handle করে। প্ল্যাটফর্ম money out পাঠানোর আগে বা compliance provider-কে call করার আগে ইউজারের available balance-এর বিপরীতে প্রয়োজনীয় amount reserve করে। ইউজার এখনও fund-এর মালিক, কিন্তু সিস্টেম অন্য transaction-কে একই অর্থ খরচ করা থেকে আটকায়। গাইডটি একটি কঠোর শর্ত পরিষ্কার করে: balance check করা এবং reservation record করা শক্তিশালী consistency চায়। একটি stale read একই funds-এর বিপরীতে দুইটি withdrawal পাস করতে দিতে পারে।

হ্যান্ডবুকটি pretend করে না যে reservation overdraft দূর করে। External system settlement প্রত্যাশার চেয়ে বেশি হলে, reversal, chargeback, বা বিলম্বিত fee-এর কারণে negative balance forced হতে পারে। গাইডটি ইঞ্জিনিয়ারদের unsigned type বা এমন database constraint ব্যবহার না করতে সতর্ক করে, যা বাস্তবতাকে reject করে। যে সিস্টেম negative balance প্রকাশ করতে পারে না, সেটি crash করতে পারে, value-কে শূন্যে clamp করতে পারে, অথবা খারাপ repair path দিয়ে money mint করতে পারে। হ্যান্ডবুকটি টিমকে overdraft book করতে, তা তদন্ত করতে, এবং ভবিষ্যতের deposit, repayment, অথবা loss account-এর মাধ্যমে recover করতে বলে।

বাহ্যিক integration-গুলোকেও একই অবিশ্বাসের দৃষ্টিতে দেখা হয়। Payment processor, bank, custodian, KYC vendor, AML vendor, blockchain node, এবং internal service - সবাই malformed payload, stale record, duplicate message, বা নীরবতা ফিরিয়ে দিতে পারে। হ্যান্ডবুকটি টিমকে তাদের নির্ভরশীল fields validate করতে, request ও response queryable form-এ store করতে, এবং traffic limit উন্মোচিত করার আগে provider quota-এর বিরুদ্ধে napkin math চালাতে পরামর্শ দেয়।

ওয়েবহুককে কঠোরভাবে দেখা হয়। একটি webhook-এর কাজ হওয়া উচিত যাচাই শুরু করা, কোনো fact settle করা নয়। গাইডটি raw bytes-এর ওপর signature যাচাই, raw payload সংরক্ষণ, দ্রুত acknowledge করা, এবং request path-এর বাইরে কাজ process করার সুপারিশ করে। টিমগুলোকে provider-এর API-তে query করে বর্তমান state দেখতে হবে এবং যে webhook কখনও আসে না সেগুলোর জন্য reconciliation job তৈরি করতে হবে। একই event দুইবার বা অর্ডারের বাইরে আসতে পারে, তাই webhook handler-দের idempotency এবং state check দরকার।

হ্যান্ডবুকটি সেই প্যাটার্নকে reliable publishing-এর সঙ্গে যুক্ত করে। একটি system যদি তার database update করে এবং আলাদা ধাপে Kafka event বা outbound webhook পাঠায়, তবে দুইয়ের মাঝখানে ব্যর্থ হতে পারে। গাইডটি outbox pattern, change data capture, এবং event sourcing-কে ব্যবহারিক উত্তর হিসেবে বর্ণনা করে। Debezium, AWS Database Migration Service, Temporal, Camunda, এবং AWS Step Functions-এর মতো tool এই ক্ষেত্রের কিছু অংশ কভার করে, যদিও প্রত্যেকটির নিজস্ব model এবং operations burden আছে।

রিকনসিলিয়েশন backstop হিসেবে কাজ করে। হ্যান্ডবুকটি টিমকে তাদের ledger-কে processor, bank, custodian, blockchain, এবং অন্য স্বাধীন source-এর সঙ্গে তুলনা করতে উৎসাহিত করে। অমিল মানে হতে পারে missing data, ভিন্ন amount, stale settlement, অথবা one-to-many batch transfer। গাইডটি কোনো report green দেখাতে এক side overwrite না করতে সতর্ক করে। ইঞ্জিনিয়ারদের প্রথম শ্রেণির correction, reprocessing path, এবং settlement timing-কে সম্মান করে এমন matching logic দরকার।

Controls section-এর মাধ্যমে কোম্পানির ভেতরের কর্মী ও সিস্টেমের প্রতিও distrust-এর ধারণা বিস্তৃত হয়। সংবেদনশীল money operation, fee change, production deployment, এবং infrastructure change-এর জন্য segregation of duties বা maker-checker approval প্রয়োজন হতে পারে। Approval-এর নিজস্ব record লাগবে: requester, approver, reason, timestamp, এবং একই ব্যক্তি দুই ভূমিকাই পালন করেনি তার প্রমাণ। Access control-ও least privilege, role-based access, change trail, এবং periodic review-এর মাধ্যমে একইভাবে扱া পায়।

Testing chapter-টি financial state-এর জন্য example-based check-এর চেয়ে ভালোভাবে মানানসই কৌশল দিয়ে হ্যান্ডবুক শেষ করে। Property-based testing operation sequence generate করতে পারে এবং প্রতিটি ধাপের পরে বইয়ের হিসাব মেলে কি না তা assert করতে পারে। Crash injection দীর্ঘ-running flow-এর প্রতিটি ধাপ জোড়ার মাঝখানে process kill করে দেখাতে পারে যে worker সেটি resume করতে পারে। Golden test fee breakdown বা statement-কে reviewed output-এর সঙ্গে pin করে রাখতে পারে। Backward-compatibility test schema change-এর পরেও পুরোনো event payload পড়ার যোগ্য রাখতে পারে।

হ্যান্ডবুকের end-to-end উদাহরণগুলো এই pattern-গুলোকে concrete করে। একটি crypto withdrawal-এ idempotent submission, funds reservation, compliance check, on-chain broadcast, confirmation depth, ledger posting, fee settlement, এবং chain reconciliation একসঙ্গে কাজ করে। একটি card deposit দেখায় কেন platform-এর উচিত capture webhook-কে signal হিসেবে ধরা, clearing account-এর মাধ্যমে credit করা, settlement-এর জন্য অপেক্ষা করা, এবং chargeback linked reversal-এর মাধ্যমে handle করা। একটি in-app conversion-এর সঙ্গে cashback দেখায় কেন spread, rounding, reference rate, এবং promotional money - সবকিছুর জন্যই ledger entry দরকার।

প্রকল্পটি funding, investor, বা commercial launch ঘোষণা করে না। এর বাজার অবস্থান আসে এক ভিন্ন ঘাটতি থেকে: অনেক ইঞ্জিনিয়ার শক্তিশালী distributed systems skill নিয়ে fintech-এ আসেন, কিন্তু accounting, settlement, custody, sanctions check, chargeback, এবং audit evidence-এর exposure কম থাকে। হ্যান্ডবুকটি এসব উদ্বেগকে finance folklore না করে software pattern হিসেবে প্যাকেজ করে।

এ কারণে গাইডটি fintech startup-এর বাইরেও উপকারী। যে কোনো টিম যা balance সংরক্ষণ করে, asset সরায়, promotional fund credit করে, financial report emit করে, বা payment provider-এর সঙ্গে integrate করে, সেই একই চাপের মুখে পড়ে। Money software service, timestamp, retry, এবং human override-এর ফাঁকে ব্যর্থ হয়। হ্যান্ডবুকটি ইঞ্জিনিয়ারদের সেই ফাঁকগুলোর জন্য একটি vocabulary এবং code-এ রূপ দেওয়া যায় এমন controls-এর সেট দেয়।