Boolean Middleware Checks — Feature Flag Control for Checkout API Routes

E-ticarətdə Kritik Yollar və “Feature Flag” Paradoksu

Müasir proqram təminatı mühəndisliyində funksionallıq bayraqları (Feature Flags) sistemin dayanıqlığını təmin edən ən kritik alətlərdən biridir. Xüsusilə e-ticarət platformalarının ödəniş marşrutlarında (checkout hot path) feature flag-in əsas məqsədi yeni bir funksiyanı tətbiq etməkdən daha çox, uğursuzluq anında sistemi dərhal və risksiz əvvəlki vəziyyətinə qaytarmaqdır (rollback). Əgər yeni bir xüsusiyyətin geri çağırılması onun canlı mühitə çıxarılmasından (deployment) daha çox vaxt və risk tələb edirsə, bu, arxitekturanın düzgün qurulmadığını göstərir.

Ödəniş axını yüksək həcmli tranzaksiyaların və sıfır xəta tələbinin olduğu bir zonadır. Burada tətbiq edilən hər bir arxitektura qərarı performansa və təhlükəsizliyə birbaşa təsir edir. Ən böyük xətalardan biri isə hər bir HTTP sorğusu üçün uzaq (remote) konfiqurasiya xidmətinə sorğu göndərmək və ya bayraqları autentifikasiya/avtorizasiya mexanizmi kimi qələmə verməkdir.

Kritik Marşrutlarda Uzaq Xidmət Zənglərinin Təhlükəsi

API marşrutunun “hot path” (yüksək tezlikli və kritik icra xətti) daxilində üçüncü tərəf və ya mərkəzləşdirilmiş uzaq Feature Flag xidmətinə şəbəkə sorğusu (HTTP/gRPC) göndərmək aşağıdakı ciddi riskləri yaradır:

• Şəbəkə Gecikməsi (Network Latency): Hər ödəniş sorğusuna əlavə 30-100ms gecikmə daxil olur ki, bu da konversiya faizini aşağı salır.
• Tək Uğursuzluq Nöqtəsi (Single Point of Failure – SPOF): Feature flag xidmətində baş verən nasazlıq bütün checkout prosesini dayandıra bilər.
• Kaskad Qəzalar (Cascading Failures): Uzaq xidmətdəki sorğu müddətinin aşılması (timeout) ödəniş servislərinin resurslarını (thread/connection pool) tükəndirir.

Bu səbəbdən qızıl qayda belədir: is_enabled məntiqi icazə səlahiyyəti (authorization) deyil, sadəcə keşlənmiş idarəetmə girişidir (cached control input). Qərarlar mütləq şəkildə servisin lokal yaddaşındakı ən son anlıq görüntü (local snapshot) üzərindən icra edilməlidir.

Düzgün Memarlıq Modeli: Middleware və Lokal Snapshot

Dayanıqlı bir checkout arxitekturası üçün bu model tətbiq edilməlidir:

1. Dövrədən Kənar Sinxronizasiya: Feature flag idarəetmə panelindən məlumatlar arxa planda işləyən asinxron proses (worker, streaming connection və ya pub/sub) vasitəsilə mütəmadi olaraq lokal yaddaşa (RAM) gətirilir və versiyalaşdırılmış snapshot halında saxlanılır.
2. Middleware Səviyyəsində Tək Yoxlanış: Sorğu checkout API marşrutuna daxil olduqda, HTTP Middleware həmin lokal snapshot-dan bayrağın vəziyyətini bir dəfə yoxlayır.
3. Kontekstin Zənginləşdirilməsi: Yoxlamanın nəticəsi (məsələn, true və ya false) və snapshot-un reviziya nömrəsi (revision ID) sorğu kontekstinə (Request Context) əlavə edilir.
4. İcra və Telemetriya: Biznes məntiqi yalnız bu kontekst məlumatını oxuyur; heç bir əlavə xarici I/O əməliyyatı aparılmır.

Praktiki Nümunə: Node.js və Express ilə Dayanıqlı Middleware Quraşdırılması

Aşağıda checkout marşrutları üçün lokal snapshot əsaslı Feature Flag yoxlanışını təmin edən konseptual tətbiq göstərilmişdir.

Addım 1: Lokal Snapshot İdarəedicisi (Snapshot Manager)

Arxa planda məlumatları keşləyən və reviziya izləməsi aparan struktur:

npm install express dotenv

// flagManager.js
class FlagManager {
    constructor() {
        this.snapshot = {
            flags: new Map(),
            revision: 0
        };
    }

    // Bu funksiya arxa planda (məs: hər 10 saniyədən bir və ya webhook ilə) çağırılır
    updateSnapshot(newFlags, revision) {
        const flagMap = new Map(Object.entries(newFlags));
        this.snapshot = {
            flags: flagMap,
            revision: revision
        };
    }

    evaluate(flagKey, defaultValue = false) {
        if (!this.snapshot.flags.has(flagKey)) {
            return { enabled: defaultValue, revision: this.snapshot.revision };
        }
        return {
            enabled: Boolean(this.snapshot.flags.get(flagKey)),
            revision: this.snapshot.revision
        };
    }
}

const flagManagerInstance = new FlagManager();
// İlkin konfiqurasiya nümunəsi
flagManagerInstance.updateSnapshot({ "new_payment_flow_v2": true }, 1042);

module.exports = flagManagerInstance;

Addım 2: Express Middleware-in Qurulması

Sorğu kontekstini bloklamayan və qərarı kontekstə daxil edən ara qat:

// flagMiddleware.js
const flagManager = require('./flagManager');

function createFlagMiddleware(flagKey, defaultValue = false) {
    return (req, res, next) => {
        // Yalnız lokal yaddaşdan oxunur - heç bir xarici I/O yoxdur
        const decision = flagManager.evaluate(flagKey, defaultValue);

        // Nəticə və reviziya request kontekstinə bağlanır
        req.featureFlags = req.featureFlags || {};
        req.featureFlags[flagKey] = {
            isEnabled: decision.enabled,
            revision: decision.revision
        };

        next();
    };
}

module.exports = createFlagMiddleware;

Addım 3: Checkout Marşrutu və Telemetriya

Kontekstdən istifadə edərək əməliyyatın aparılması və məhdud telemetriyanın göndərilməsi:

// server.js
const express = require('express');
const createFlagMiddleware = require('./flagMiddleware');

const app = express();
app.use(express.json());

app.post('/api/v1/checkout', 
    createFlagMiddleware('new_payment_flow_v2', false), 
    (req, res) => {
        const { isEnabled, revision } = req.featureFlags['new_payment_flow_v2'];

        // Telemetriya üçün məhdud metadata
        const telemetryData = {
            flag: 'new_payment_flow_v2',
            state: isEnabled,
            revision: revision,
            timestamp: Date.now()
        };

        // Telemetriyanı qeydə al (Məs: Prometheus və ya OpenTelemetry log)
        console.log("[TELEMETRY]", JSON.stringify(telemetryData));

        if (isEnabled) {
            // Yeni optimallaşdırılmış ödəniş mexanizmi
            return res.status(200).json({ status: "success", engine: "v2", revision });
        } else {
            // Əvvəlki stabil ödəniş mexanizmi
            return res.status(200).json({ status: "success", engine: "v1_legacy", revision });
        }
});

app.listen(3000, () => {
    console.log("Checkout servisi 3000 portunda aktivdir.");
});

Süni İntellekt (AI) Agentləri və Checkout Dövrəsində Telemetriya

Son dövrlərdə avtonom süni intellekt agentlərinin istifadəçilər adından alış-veriş etdiyi və checkout əməliyyatlarını yönləndirdiyi ssenarilər genişlənir. AI agentlərin daxil olduğu bu dövrlərdə sistemin qərarvermə mexanizmi deterministik olmalıdır.

Əgər agent checkout prosesində qeyri-müəyyən vəziyyətlə qarşılaşarsa, telemetriya məlumatları mütləq şəkildə hansı feature flag konfiqurasiyasının və hansı snapshot reviziyasının aktiv olduğunu dəqiq əks etdirməlidir. Telemetriyanın həcmi məhdudlaşdırılmalı (bounded telemetry), sonsuz log axını əvəzinə yalnız reviziya ID-si, qərarın nəticəsi və gecikmə metrikaları qeydə alınmalıdır. Bu, həm observability xərclərini azaldır, həm də agentin səhv addım atması halında problemin kökünü dərhal tapmağa kömək edir.

Sənaye və Biznes Təsiri: Niyə Bu Yanaşma Standart Olmalıdır?

E-ticarətdə bir neçə dəqiqəlik dayanma (downtime) yüz minlərlə manatlıq maliyyə itkisi və reputasiya zərbəsi deməkdir. Təsvir olunan memarlıq modelinin sektora təsirləri bunlardır:

• Sıfır Gecikmə Təsiri: Feature flag qiymətləndirilməsi mikrosaniyələr daxilində (in-memory) baş verir, istifadəçi təcrübəsinə heç bir mənfi təsir göstərmir.
• Kill-Switch Effektivliyi: Yeni buraxılan ödəniş axınında hər hansı anomaliya aşkarlandıqda, mərkəzi paneldən bayraq söndürülür və saniyələr ərzində yeni snapshot bütün instansiyalara yayılır. Kodun yenidən deploy edilməsinə ehtiyac qalmır.
• Yüksək Dayanıqlıq: Hətta feature flag təminatçısının serverləri tamamilə sıradan çıxsa belə, checkout servisi sonuncu etibarlı snapshot ilə fəaliyyətini davam etdirir.

Nəticə

Ödəniş axınlarında tətbiq edilən feature flag-lər kodun sadəcə bir qolunu açıb-bağlamaqdan daha artıq məna daşıyır. Onlar sistemin risk sığortasıdır. Əsas qaydanı yadda saxlamaq vacibdir: Heç vaxt hot path üzərində uzaq xidmətlərə güvənməyin, bayraq qiymətləndirməsini lokal snapshot vasitəsilə middleware qatında həyata keçirin və hər bir qərarı dəqiq telemetriya ilə bağlayın.