কিভাবে এটা কাজ করে?

সীমারেখা স্পষ্ট রাখা সবচেয়ে সহজ আর্কিটেকচার দিয়ে শুরু করুন

একটি নতুন বিনিয়োগ প্ল্যাটফর্মে একটি মাত্র টিম, একটি ডিপ্লয়মেন্ট এবং একটি ডেটাবেস থাকে। এই পর্যায়ে বিতরণকৃত সিস্টেমের খরচ সম্পূর্ণভাবে ওভারহেডে চলে যায়: এমন জায়গায় নেটওয়ার্ক কল যেখানে একটি ফাংশন কলই যথেষ্ট হতো, এমন জায়গায় eventual consistency যেখানে একটি ট্রানজেকশনই যথেষ্ট হতো, এবং এমন অপারেশনাল বোঝা যার জন্য কোনো জনবল নেই।

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

একটি সার্ভিস তখনই আলাদা করা হয় যখন এর যথাযথ কারণ থাকে

একটি মডিউল একটি স্বতন্ত্র সার্ভিসে পরিণত হয় নির্দিষ্ট কারণে, এবং এই কারণগুলো ব্যবসায়িক, ফ্যাশনেবল নয়:

যেহেতু সীমারেখা এবং চুক্তিগুলো ইতিমধ্যে বিদ্যমান, তাই সার্ভিস আলাদা করা একটি পরিকল্পিত কার্যক্রম, পুনর্লিখন নয়। এটাই মূল বিষয়: বিকল্পটি খোলা থাকে এবং সস্তা থাকে।

যেখানে এটি প্রয়োজনীয়, সেখানে অ্যাসিঙ্ক্রোনাস প্রক্রিয়াকরণ

যে কাজ ব্যবহারকারীকে আটকে রাখা উচিত নয় — সেটেলমেন্ট রিকনসিলিয়েশন, ডকুমেন্ট জেনারেশন, প্রোভাইডার কলব্যাক, রিপোর্টিং — কিউ-এর মাধ্যমে চলে। RabbitMQ বা Kafka-এর মতো মেসেজ ব্রোকারগুলো তখনই আসে যখন থ্রুপুট বা ইন্টিগ্রেশন টপোলজি তা যুক্তিসঙ্গত করে তোলে, ডিফল্ট হিসেবে নয়। PostgreSQL রেকর্ডের সিস্টেম হিসেবেই থেকে যায়; Redis ব্যবহৃত হয় যেখানে সত্যিই দ্রুতগতির ক্যাশ বা সমন্বয় প্রয়োজন।

আমরা যা করি না

আমরা একটি monolith বিক্রি করি না, এবং মাইক্রোসার্ভিসও বিক্রি করি না। দুটোই এমন প্রশ্নের উত্তর যা এখনো কেউ জিজ্ঞাসা করেনি। আমরা প্ল্যাটফর্মকে গুরুত্বপূর্ণ দেখাতে বিতরণকৃত সিস্টেমও তৈরি করি না — আর্কিটেকচার থিয়েটার চালাতে ব্যয়বহুল এবং হস্তান্তর করা কঠিন।

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