David Shergilashvili’s Post

Trying to work remotely after a morning call #devlife

A programmer from a family of vampires #devlife

პროგრამირება მხოლოდ პროფესია კი არა, ცხოვრების წესია. ის მოითხოვს სიყვარულს, ერთგულებას და მუდმივ სწავლას. Programming is not just a profession, it's a way of life. It requires love, commitment, and constant learning. #devlife

Financial Services Data Consistency in Microservice Architecture 🏦💸 Maintaining data consistency and reliable transaction coordination between services is a major challenge in microservice-based banking systems. Let's consider a few scenarios and the corresponding approaches: 📌 Scenario 1 - Card Transaction During a card transaction, it's necessary to update the client's balance and simultaneously send transaction details to the payment gateway and fraud detection services. Solution: Transactional Outbox - Transaction details are written to both the main table and the Outbox table within a single transaction. Then a separate service sends messages from the Outbox. 📌 Scenario 2 - Opening a New Account A user opens a new bank account. It's required to create a profile, open an account, and send a welcome email. Solution: Transactional Outbox - The account creation service creates a record in the database and writes a message about sending an email to the Outbox within a single transaction. 📌 Scenario 3 - Loan Application Status Change During loan application processing, the loan manager changes the application status. This change should be reflected in all relevant services (notification, reporting). Solution: Transaction Log Tailing - Database changes are streamed in real-time using CDC (Change Data Capture) mechanism and delivered to interested services. 📌 Scenario 4 - Incoming Transactions from eTrade System Financial transactions enter the banking core system from the eTrade platform, which need to be processed in a transactional mode. Solution: Transactional Inbox + Outbox - Events received from the eTrade system are written to the Inbox, processed transactionally, and if necessary, messages are sent using the Outbox. If we take the .NET stack, a typical Transactional Outbox implementation can be formed as follows: - Database - Microsoft SQL Server - ORM framework - Entity Framework Core - Writing to Outbox table within a transaction - EF Core TransactionScope - Outbox processor service - .NET Worker Service or Hangfire - Streaming messages - Kafka Client or Azure Event Hub SDK And if we take the Transactional Log Tailing approach: - SQL Server CDC for capturing changes - Kafka Connect / Debezium Connector for streaming CDC events - Kafka or Azure Event Hub for caching and distributing events - Event consumer services - .NET Kafka Client or Azure Event Processor #microservices #transactionaloutbox #transactionalinbox #changedata

ფინანსური სერვისების მონაცემთა თანმიმდევრულობა მიკროსერვისულ არქიტექტურაში 🏦💸 მიკროსერვისებზე დაფუძნებულ საბანკო სისტემებში მონაცემთა თანმიმდევრულობის შენარჩუნება და სერვისებს შორის ტრანზაქციების საიმედო კოორდინაცია დიდ გამოწვევას წარმოადგენს. განვიხილოთ რამდენიმე სცენარი და შესაბამისი მიდგომები: 📌 სცენარი 1 - საბარათე ტრანზაქცია საბარათე ტრანზაქციის დროს საჭიროა კლიენტის ნაშთის განახლება და ამავდროულად ტრანზაქციის დეტალების გაგზავნა გადახდის გეითვეისა და fraud detection სერვისებისთვის. გადაწყვეტა: Transactional Outbox - ტრანზაქციის დეტალები ჩაიწერება როგორც ძირითად, ასევე Outbox ცხრილში ერთი ტრანზაქციის ფარგლებში. შემდეგ ცალკე სერვისი გააგზავნის შეტყობინებებს Outbox-იდან. 📌 სცენარი 2 - ახალი ანგარიშის გახსნა მომხმარებელი ხსნის ახალ საბანკო ანგარიშს. საჭიროა პროფილის შექმნა, ანგარიშის გახსნა და მისასალმებელი ემაილის გაგზავნა. გადაწყვეტა: Transactional Outbox - ანგარიშის შექმნის სერვისი ტრანზაქციის ფარგლებში შექმნის ჩანაწერს მონაცემთა ბაზაში და ჩაწერს შეტყობინებას ემაილის სერვისისთის გაგზავნის შესახებ Outbox-ში. 📌 სცენარი 3 - სესხის განაცხადის სტატუსის ცვლილება სესხის განაცხადის დამუშავების პროცესში, სესხის მენეჯერი ცვლის განაცხადის სტატუსს. ეს ცვლილება უნდა აისახოს ყველა შესაბამის სერვისში (ნოტიფიკაცია, რეპორტინგი). გადაწყვეტა: Transaction Log Tailing - მონაცემთა ბაზის ცვლილებები რეალურ დროში სტრიმდება CDC (Change Data Capture) მექანიზმით და მიეწოდება დაინტერესებულ სერვისებს. 📌 სცენარი 4 - eTrade სისტემიდან შემოსული ტრანზაქციები  eTrade პლატფორმიდან საბანკო core სისტემაში შემოდის ფინანსური ტრანზაქციები, რომლებიც უნდა დამუშავდეს ტრანზაქციულ რეჟიმში. გადაწყვეტა: Transactional Inbox + Outbox - eTrade სისტემიდან მიღებული მოვლენები ჩაიწერება Inbox-ში, დამუშავდება ტრანზაქციულად და საჭიროების შემთხვევაში გაიგზავნება შეტყობინებები Outbox-ის გამოყენებით. თუ ავიღებთ .NET სტეკს, ტიპიური Transactional Outbox იმპლემენტაცია შეიძლება ჩამოყალიბდეს ასე: - მონაცემთა ბაზა - Microsoft SQL Server - ORM ფრეიმვორკი - Entity Framework Core  - Outbox ცხრილში ჩაწერა ტრანზაქციის ფარგლებში - EF Core TransactionScope - Outbox processor სერვისი - .NET Worker Service ან Hangfire  - შეტყობინებების სტრიმინგი - Kafka Client ან Azure Event Hub SDK ხოლო თუ ავიღებთ Transactional Log Tailing მიდგომას: - SQL Server CDC ცვლილებების ასაღებად - Kafka Connect / Debezium Connector CDC ივენთების სტრიმინგისთვის - Kafka ან Azure Event Hub ივენთების ქეშირებისა და დისტრიბუციისთვის - ივენთების მომხმარებლი სერვისები - .NET Kafka Client ან Azure Event Processor #banking #fintech #microservices #consistency #transactionaloutbox #cdc

#devlife

Application of CAP Theory in Different Banking Scenarios: Choices and Best Practices CAP (Consistency, Availability, Partition Tolerance) theory describes three fundamental characteristics that cannot be satisfied simultaneously in a distributed system. This theory is particularly relevant in the banking sector, where decisions on priorities must be made considering various business scenarios. Let's consider some examples: Scenario 1: Online banking transactions When it comes to online transactions, data consistency and partition tolerance are of the utmost importance for banks. Customers need to be sure that transactions are reflected accurately and money is not lost in case of network problems. In this case, the system may become temporarily unavailable (Unavailable) under high load, but all actions will be reflected correctly in the end. Scenario 2: ATM service The money issued by the ATM must be consistent with the change in the user's balance. However, the ATM must work even during network problems, as it is often used in an emergency. At this time, it is possible to make some compromise and focus on availability. Money is issued locally, and the balance is updated when the connection to the central server is restored (Eventual Consistency). Scenario 3: Credit history report A credit history report should contain up-to-date and consistent records about consumers, as this information is critical to the lending decision. This functionality is less dependent on the system's real-time availability (Availability), as reports are generated at certain intervals and may be delayed during network problems. Within the .NET platform there are many tools that will help us to correctly configure each component of the system taking into account the CAP theory. For example, with Entity Framework Core we can ensure data consistency, we will use MS SQL Database functionality for replication. For communication between system components, we use asynchronous messages via RabbitMQ, which increases the resistance to fragmentation. To balance the load, we will run the services in a Kubernetes cluster and add Autoscaling functionality. For high availability and in-memory databases such as Redis, which provides fast reading. With constant monitoring, incident management and flexible architecture, we will achieve high quality of banking services. CAP theory needs to be considered when adding new functionality to mitigate risks. #captheorem

CAP თეორიის გამოყენება სხვადასხვა საბანკო სცენარებში: არჩევანის გაკეთება და საუკეთესო პრაქტიკები CAP (Consistency, Availability, Partition Tolerance) თეორია აღწერს სამ ფუნდამენტურ მახასიათებელს, რომელთა ერთდროულად დაკმაყოფილება შეუძლებელია დისტრიბუირებულ სისტემაში. ეს თეორია განსაკუთრებით აქტუალურია საბანკო სექტორში, სადაც გადაწყვეტილება უნდა მივიღოთ პრიორიტეტების შესახებ სხვადასხვა ბიზნეს სცენარის გათვალისწინებით. მოდით, განვიხილოთ რამდენიმე მაგალითი: სცენარი 1: ონლაინ საბანკო ტრანზაქციები როდესაც საქმე ეხება ონლაინ ტრანზაქციებს, ბანკებისთვის უმნიშვნელოვანესია მონაცემთა თანმიმდევრულობა (Consistency) და ქსელის დანაწევრებისადმი მდგრადობა (Partition Tolerance). მომხმარებლები უნდა იყვნენ დარწმუნებული, რომ ტრანზაქციები აისახება ზუსტად და ფული არ დაიკარგება ქსელის პრობლემების შემთხვევაში. ამ შემთხვევაში სისტემა შეიძლება დროებით უხელმისაწვდომო (Unavailable) გახდეს მაღალი დატვირთვის ქვეშ, მაგრამ ყველა ქმედება საბოლოოდ აისახება სწორად. სცენარი 2: ბანკომატის სერვისი ბანკომატის მიერ გაცემული ფული უნდა იყოს თანმიმდევრული (Consistent) მომხმარებლის ნაშთის ცვლილებასთან. თუმცა, ბანკომატი უნდა მუშაობდეს ქსელის პრობლემების დროსაც, რადგან ხშირად მას იყენებენ სასწრაფოდ. ამ დროს შესაძლებელია გარკვეული კომპრომისის გაკეთება და წვდომადობაზე (Availability) ფოკუსირება. ფული გაიცემა ლოკალურად, ხოლო ნაშთი განახლდება ცენტრალურ სერვერთან კავშირის აღდგენისას (Eventual Consistency). სცენარი 3: საკრედიტო ისტორიის რეპორტი საკრედიტო ისტორიის რეპორტი უნდა შეიცავდეს მომხმარებლების შესახებ უახლეს და თანმიმდევრულ (Consistent) ჩანაწერებს, რადგან ეს ინფორმაცია კრიტიკულია სესხის გაცემის გადაწყვეტილებისთვის. ეს ფუნქციონალი ნაკლებად არის დამოკიდებული სისტემის რეალურ დროში ხელმისაწვდომობაზე (Availability), რადგან რეპორტები იქმნება გარკვეული ინტერვალით და შესაძლოა დაყოვნდეს ქსელის პრობლემების დროს. .NET პლატფორმის ფარგლებში არსებობს მრავალი ინსტრუმენტი, რომლებიც დაგვეხმარება სისტემის თითოეული კომპონენტის სწორ კონფიგურაციაში CAP თეორიის გათვალისწინებით. მაგალითად, Entity Framework Core-ით შეგვიძლია მონაცემთა თანმიმდევრულობის უზრუნველყოფა, რეპლიკაციისთვის გამოვიყენებთ MS SQL Database-ის ფუნქციონალს. სისტემის კომპონენტებს შორის კომუნიკაციისთვის ვიყენებთ ასინქრონულ შეტყობინებებს RabbitMQ -ის მეშვეობით, რაც ზრდის დანაწევრებისადმი მდგრადობას. დატვირთვის დასაბალანსებლად გავუშვებთ სერვისებს Kubernetes კლასტერში და დავამატებთ Autoscaling ფუნქციონალს. მაღალი წვდომადობისთვის ასევე in-memory ბაზები, როგორიცაა Redis, რომელიც სწრაფ წაკითხვას უზრუნველყოფს. მუდმივი მონიტორინგით, ინციდენტების მართვით (Incident Management) და მოქნილი არქიტექტურით მივაღწევთ საბანკო სერვისების მაღალ ხარისხს. საჭიროა CAP თეორიის გათვალისწინება ყოველი ახალი ფუნქციონალის დამატებისას რისკების შესამცირებლად.

6️⃣ პლატფორმული ინჟინერია - 2024 წლის ერთ-ერთი ტოპ ტრენდი 🚀 Gartner-ის პროგნოზით, 2026 წლისთვის პროგრამული უზრუნველყოფის შემუშავების ორგანიზაციების 80% შექმნის პლატფორმულ გუნდებს, რომლებიც აპლიკაციების მისაწოდებლად უზრუნველყოფენ მრავალჯერადი გამოყენების სერვისებს, კომპონენტებსა და ინსტრუმენტებს. ფოკუსი იქნება დეველოპერების პროდუქტიულობის გაზრდაზე შემდეგი მეთოდებით: ✅ თვითმომსახურების შესაძლებლობები  ✅ უწყვეტი ინტეგრაცია და განთავსება ✅ ინფრასტრუქტურის ავტომატიზაცია ✅ AI-ზე დაფუძნებული პროგრამული უზრუნველყოფის შემუშავება შიდა პლატფორმების აგება რჩება ტრენდად მათი ორგანიზაციისა და გუნდის საჭიროებებზე მორგების გამო. თუმცა, ამ პროცესში ტექნოლოგიებზე მეტად მნიშვნელოვანია ეფექტური ინჟინრული პრაქტიკა და ორგანიზაციული კულტურა დეველოპერების კეთილდღეობისთვის. პლატფორმული ინჟინერიის გუნდის ეფექტურად ჩამოსაყალიბებლად საუკეთესო მიდგომად მიიჩნევა გუნდების ტოპოლოგიების გამოყენება. რაც შეეხება პროდუქტიულობისა და ინჟინრული მეტრიკების შეფასებას, ამისთვის რეკომენდებულია ისეთი ჩარჩოების გამოყენება, როგორებიცაა DORA (2018), SPACE (2021) და DevEx (2023). სწორედ ამ ინსტრუმენტებით გააგრძელებენ ენტერპრაიზ ორგანიზაციები მეტრიკების მონიტორინგს. ასევე, გრძელდება ექსპერიმენტები "infrastructure-from-code"-ის ტრენდით, რათა დეველოპერებმა შეძლონ ღრუბლოვანი ინფრასტრუქტურის მართვა საყვარელი პროგრამირების ინტერფეისით ან ახალი ენებით, როგორიცაა Winglang. #PlatformEngineering #DeveloperProductivity #EngineeringMetrics #InternalPlatform #TechTrends2024

#devlife