Architecture Decision Lab

Qərar verin. Nəticəsini görün.

Hər ssenari real komanda situasiyasıdır. Bir variant seçin — nə baş verəcəyini, trade-off-u və hansı şəraitdə başqa variantın daha yaxşı olacağını görəcəksiniz.

Ssenarilər Azərbaycan dilindədir.

0 / 6 ssenari

01 · Middle

Sifariş yaradılanda anbar və e-poçt xəbərdar olunmalıdır

Order service sifarişi PostgreSQL-ə yazır, sonra anbar (inventory) servisini məlumatlandırmalı və müştəriyə təsdiq e-poçtu göndərdirməlidir. Pik vaxtda təxminən 200 sifariş/saniyə gözlənilir (qəbul edilmiş fərziyyə). E-poçt provayderi bəzən yavaşlayır və ya qısa müddətlik əlçatmaz olur. Komanda artıq Kafka cluster-i işlədir.

Məhdudiyyətlər

Sifariş qəbulu e-poçt provayderinin yavaşlığından asılı olmamalıdır.
Təsdiqlənmiş sifariş üçün anbar bildirişi itirilməməlidir.
Komanda 4 nəfərdir və yeni infrastruktur əlavə etmək istəmir.

Bu bildirişləri necə çatdırmaq lazımdır?

Order service sifarişi yazandan sonra anbar və e-poçt servislərini ardıcıl REST ilə çağırır.Sifarişi və "outbox" cədvəlindəki hadisəni eyni transaction-da yazmaq, ayrıca relay prosesi ilə hadisəni Kafka-ya göndərmək; anbar və e-poçt consumer-ləri müstəqil oxuyur.Order service transaction-dan sonra birbaşa Kafka-ya hadisə göndərir (outbox olmadan).Anbar və e-poçt servisləri eyni verilənlər bazasındakı ortaq "tasks" cədvəlini periodik oxuyur.

02 · Middle

Məhsul kataloqu: sürətli oxuma, amma qiymət tez görünməlidir

Kataloq API-si oxuma-ağırlıqlıdır: təxminən 2000 oxuma/saniyə, yazma isə dəqiqədə bir neçə dəfə (qəbul edilmiş fərziyyə). Məhsul məlumatı PostgreSQL-dədir və verilənlər bazası pikdə yüklənir. Qiymət dəyişikliyi müştərilərə ən çox bir dəqiqə ərzində görünməlidir. Komandada Redis artıq istifadə olunur.

Məhdudiyyətlər

Qiymət dəyişikliyi görünmə gecikməsi ən çox 1 dəqiqə.
Verilənlər bazasına oxuma yükü azalmalıdır.
Mürəkkəb invalidation məntiqini idarə edəcək vaxt yoxdur.

Hansı cache strategiyası bu şərtlərə ən uyğundur?

Cache-aside: Redis-də 30–60 saniyəlik qısa TTL, qiymət yenilənəndə açarı silmək, popular açarlarda stampede qorunması.Uzun TTL (məsələn, 24 saat) və yalnız əl ilə cache təmizləmə.Cache yoxdur; verilənlər bazasına index əlavə edib sorğuları optimallaşdırmaq.Write-through cache: hər yazmada həm bazaya, həm cache-ə yazmaq, TTL olmadan.

03 · Senior

Deploy yavaşdır, komanda mikroservis istəyir

5 nəfərlik komanda bir Spring Boot monolitini işlədir; kod modullara bölünüb, amma modullar arasında sərhədlər qanuni deyil, bir verilənlər bazası var. Deploy-lar yavaşdır, çünki CI pipeline-ı bütün testləri işlədir və hər buraxılış əl ilə yoxlanılır. Komanda "yavaş deploy" problemini həll etmək üçün mikroservislərə keçmək istəyir. Platforma/DevOps mütəxəssisi yoxdur.

Məhdudiyyətlər

Cəmi 5 mühəndis, ayrıca platforma komandası yoxdur.
Əsas ağrı deploy sürətidir, müstəqil miqyaslanma ehtiyacı yoxdur.
Biznes yeni funksiyaları gecikdirməməlidir.

İlk addım nə olmalıdır?

Bütün modulları eyni anda ayrı mikroservislərə çevirmək.Əvvəlcə monolitin deploy boru xəttini düzəltmək: testləri paralelləşdirmək, yoxlamaları avtomatlaşdırmaq, modul sərhədlərini kodda tətbiq etmək (arxitektura testləri); mikroservislər üçün konkret səbəb yaranana qədər gözləmək.Yalnız bir modulu (məsələn, bildirişlər) ayrı servis kimi çıxarmaq və nəticəni görmək.Yeni funksiyaları yalnız ayrı servislərdə yazmaq, monoliti toxunmadan saxlamaq.

04 · Senior

İki servisdə iki hesab arasında pul köçürməsi

Hazırda hesablar iki ayrı servisdə və ayrı verilənlər bazalarında saxlanılır: biri yerli hesablar, digəri xarici ödəniş hesabları üçün. İstifadəçi bir hesabdan digərinə pul köçürmək istəyir. Hər halda pul nə itməli, nə də iki dəfə yaranmalıdır. Servislər HTTP ilə danışır və şəbəkə nasazlığı mümkündür.

Məhdudiyyətlər

Pul itməməli və ikiqat yaranmamalıdır.
Servislər və bazalar ayrıdır, birgə transaction meneceri yoxdur.
Hər addım audit üçün izlənə bilməlidir.

Köçürməni necə təşkil etməli?

Two-phase commit (2PC / XA) ilə iki bazanı bir paylanmış transaction-da bağlamaq.Saga: debit addımı, sonra credit addımı; credit uğursuz olsa kompensasiya (debit-in geri qaytarılması). Hər addım idempotency açarı ilə, vəziyyət davamlı saxlanır.İki hesabı da bir servisdə və bir verilənlər bazasında saxlamaq, köçürməni adi ACID transaction kimi etmək.Debit edib "fire-and-forget" hadisə göndərmək; qəbul edən servis credit etsin, cavab gözləmədən.

05 · Senior

Hesabat paneli əməliyyat bazasını yavaşladır

Daxili hesabat paneli iş saatlarında ağır aqreqasiya sorğuları işlədir və eyni PostgreSQL-i paylaşan sifariş əməliyyatları yavaşlayır. Əməliyyat bazası bir primary instance-dır. İşçilər hesabatın bir neçə dəqiqə köhnə olmasına dözür, amma bəzi menecerlər "bu günkü satış" rəqəminin təxminən təzə olmasını istəyir. Büdcə məhduddur.

Məhdudiyyətlər

Əməliyyat sorğularının gecikməsi hesabatlardan təsirlənməməlidir.
Hesabat verilənləri bir neçə dəqiqə köhnə ola bilər.
Komanda yeni sistem əlavə etməkdə məhdud təcrübəyə malikdir.

Hesabat yükünü necə ayırmalı?

Mövcud PostgreSQL üçün read replica qurub hesabat panelini ona yönləndirmək.CDC ilə dəyişiklikləri ayrıca analitik anbara (məsələn, kolon əsaslı) axıtmaq.Primary instance-ı daha böyük (daha çox CPU/RAM) seçmək.Hesabatları gecə ixrac olunan fayllardan (nightly export) oxumaq.

06 · Architect

LLM "assistent" müştəri sifarişlərini dəyişə bilsin

Məhsul komandası müştərilərə sifarişlərini dəyişməyə (ünvan, miqdar, ləğv) kömək edən LLM əsaslı assistent istəyir. Backend-də bu əməliyyatlar üçün artıq doğrulama və səlahiyyət qaydaları olan API-lər var. Model bəzən yanlış anlaya və ya istifadəçinin mətnində gizlədilmiş təlimatlara (prompt injection) məruz qala bilər. Sifariş dəyişiklikləri maliyyə və müştəri təsiri daşıyır.

Məhdudiyyətlər

Yalnız müştəri öz sifarişini dəyişə bilməlidir.
Yanlış və ya manipulyasiya edilmiş əməliyyat zərər verməməlidir.
Əməliyyatlar izlənə və geri çağırıla bilməlidir (audit).

Assistentin sifariş dəyişmə qabiliyyətini necə dizayn etməli?

Modelə verilənlər bazasına birbaşa SQL və ya yazma girişi vermək ki, istədiyini dəyişsin.Tool calling: model yalnız dar, tipli alətləri çağırır (məsələn, "ünvanı dəyiş"), parametrlər sxemlə doğrulanır, səlahiyyət istifadəçi sessiyası ilə server tərəfdə yoxlanılır, dəyişiklik istifadəçi təsdiqindən sonra icra olunur.Əvvəlcə yalnız oxuyan assistent buraxmaq (sifariş statusu, qaydalar), dəyişiklik funksiyasını sonra əlavə etmək.LLM əvəzinə qayda əsaslı chatbot: menyu və düymələrlə əvvəlcədən müəyyən axınlar.

Bu qərarları real layihədə müdafiə etməyi öyrənmək istəyirsiniz?

System Design və Solution Architecture proqramlarına baxın və ya case müsahibəsini sınayın.

Case müsahibəsi Proqramlar