Running a two-sided marketplace on shared hosting: PHP 7.4, no framework, no cron

Mürəkkəb Bulud İnfrastrukturuna Qarşı “Köhnə Məktəb” Yanaşması

Müasir proqram təminatı mühəndisliyində kiçik bir MVP (Minimum Viable Product) hazırlayarkən belə Kubernetes klasterləri, Docker konteynerləri, Redis keş mexanizmləri, RabbitMQ kimi növbə (queue) brokerləri və mikroservis arxitekturalarına meyil etmək adi hala çevrilib. Lakin Türkiyədə fəaliyyət göstərən yerli xidmət platforması “Kimusta”-nın təcrübəsi göstərir ki, həddindən artıq mühəndislik (over-engineering) hər zaman uğurun yeganə açarı deyil.

İkitərəfli bazar platforması (müştəri və xidmət təminatçısını birləşdirən sistem) olan bu layihə heç bir müasir framework (Laravel, Symfony və s.), Node.js mühiti, Redis, növbə emalçısı (worker) və ən əsası sistem səviyyəsində işləyən avtomatlaşdırılmış “cron” tapşırıqları olmadan fəaliyyət göstərir. Bütün platforma ucuz paylaşılan hostinq (shared hosting) üzərində — köhnə hesab edilən PHP 7.4 və MariaDB 10.3 texnologiyaları ilə LiteSpeed veb serveri arxasında stabil çalışır.

Kimusta Layihəsinin Texniki Arxitekturası

Müasir startapların yüzlərlə dollar bulud (AWS, GCP) xərcləri ilə müqayisədə illik cəmi bir neçə on dollarlıq hostinq paketi ilə böyük trafik idarə etmək minimalist arxitekturanın gücünü nümayiş etdirir.

1. Vanilla PHP və Yaddaş İdarəetməsi

Müasir framework-lər (məsələn, Laravel) hər HTTP sorğusunda yüzlərlə sinfi (class), konfiqurasiya fayllarını və servis təminatçılarını (service providers) yükləyir. Bu, PHP tərəfində sorğu başına 15-30 MB RAM istifadəsinə səbəb olur. Təmiz (Vanilla) PHP 7.4 istifadəsi isə sorğu başına cəmi 1-2 MB operativ yaddaş sərf edir ki, bu da paylaşılan hostinqin sərt RAM limitlərində (adətən 512 MB və ya 1 GB) eyni anda minlərlə istifadəçiyə xidmət göstərməyə imkan verir.

2. LiteSpeed və Verilənlər Bazası İndeksləri

LiteSpeed Web Server statik faylları və HTTP keşləməni (LSCache vasitəsilə) birbaşa veb server səviyyəsində emal edir. Sorğu PHP təbəqəsinə çatmadan statik olaraq geri qaytarılır. Dinamik verilənlər üçün MariaDB 10.3 üzərində düzgün kompozit indekslərin (composite indexes) qurulması sorğuların mikrosaniyələr ərzində icrasını təmin edir və Redis-ə olan ehtiyacı aradan qaldırır.

Cron və Növbə Olmadan Arxa Plan Tapşırıqlarının Həlli

İkitərəfli bazarlarda bildirişlərin göndərilməsi, təkliflərin müddətinin bitməsi və e-poçt göndərişləri kimi arxa plan tapşırıqları vacibdir. Shared hostinqlərdə SSH çıxışı və ya etibarlı cron təyinatı olmadıqda, iki əsas mexanizm köməyə çatır:

• Pseudo-cron (Trafik əsaslı tətikləmə): Sayta daxil olan hər real istifadəçi sorğusu fon rejimində planlaşdırılmış tapşırığın vaxtının çatıb-çatmadığını yoxlayır.
• Asinxron Cavabvermə (fastcgi_finish_request): Müştəriyə HTML və ya JSON cavabı dərhal göndərilir, əlaqə kəsilir, lakin PHP skripti arxa planda e-poçt göndərmək və ya bazanı yeniləmək kimi ağır işləri tamamlamağa davam edir.

Addım-Addım Bələdçi: Shared Hostinqdə “Poor Man’s Cron” və Növbə Qurulması

Əgər serverinizdə cron və ya queue worker yoxdursa, aşağıdakı addımlarla tam işlək fon tapşırıqları mexanizmini qura bilərsiniz.

Addım 1: Tapşırıqlar Cədvəlinin Yaradılması

Arxa planda icra ediləcək işləri saxlamaq üçün MariaDB-də sadə bir cədvəl yaradılır:

# MariaDB konsolunda cədvəli yaradın:
mysql -u istifadeci -p veriler_bazasi -e "
CREATE TABLE background_jobs (
    id INT AUTO_INCREMENT PRIMARY KEY,
    task_type VARCHAR(50) NOT NULL,
    payload TEXT NOT NULL,
    status ENUM('pending', 'processing', 'completed', 'failed') DEFAULT 'pending',
    attempts INT DEFAULT 0,
    execute_after DATETIME NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_status_time (status, execute_after)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;"

Addım 2: Tapşırığı Növbəyə Əlavə Etmək

İstifadəçi saytda hər hansı əməliyyat edəndə (məsələn, usta üçün müraciət yaradanda) e-poçt birbaşa həmin saniyədə göndərilmir, növbəyə atılır:

# PHP daxilində tapşırığı bazaya qeyd etmək nümunəsi:
php -r "
\$pdo = new PDO('mysql:host=localhost;dbname=veriler_bazasi', 'istifadeci', 'shifre');
\$stmt = \$pdo->prepare('INSERT INTO background_jobs (task_type, payload, execute_after) VALUES (?, ?, NOW())');
\$stmt->execute(['send_email', json_encode(['to' => 'user@example.com', 'subject' => 'Yeni Təklif'])]);
echo 'Tapşırıq növbəyə əlavə olundu\n';
"

Addım 3: Istifadəçi Sorğusunu Gecikdirmədən İcra (FastCGI Finish Request)

Əsas veb səhifənin sonunda istifadəçiyə cavabı çatdırdıqdan dərhal sonra növbədəki işləri icra edən skript işə düşür:

# Layihənin index.php faylının sonuna əlavə edilən struktur:
cat << 'EOF' > worker_trigger.php
<?php
// 1. İstifadəçiyə səhifəni göstər
echo "<h1>Sorğunuz qəbul edildi!</h1>";

// 2. HTTP bağlantısını bağla (istifadəçi yüklənmə gözləmir)
if (function_exists('fastcgi_finish_request')) {
    fastcgi_finish_request();
}

// 3. Arxa plan rejimində növbədən işi götür və icra et
$pdo = new PDO('mysql:host=localhost;dbname=veriler_bazasi', 'istifadeci', 'shifre');

// Kilidləmə mexanizmi ilə eyni anda bir neçə sorğunun eyni işi görməsinin qarşısını alırıq
$pdo->beginTransaction();
$stmt = $pdo->query("SELECT * FROM background_jobs WHERE status = 'pending' AND execute_after <= NOW() LIMIT 1 FOR UPDATE");
$job = $stmt->fetch(PDO::FETCH_ASSOC);

if ($job) {
    $pdo->query("UPDATE background_jobs SET status = 'processing' WHERE id = " . $job['id']);
    $pdo->commit();

    // Tapşırığı icra et (Məs: mail() funksiyası ilə)
    $payload = json_decode($job['payload'], true);
    // mail($payload['to'], $payload['subject'], 'Mesaj gövdəsi...');
    
    // Tapşırığı tamamlandı olaraq işarələ
    $stmt = $pdo->prepare("UPDATE background_jobs SET status = 'completed' WHERE id = ?");
    $stmt->execute([$job['id']]);
} else {
    $pdo->rollBack();
}
EOF

Sektora və Layihə Sahiblərinə Təsiri: Nə Vaxt Sadəlik Seçilməlidir?

Kimusta layihəsinin yanaşması proqram təminatı ictimaiyyətində mühüm bir reallığı ortaya qoyur: Texnoloji yığın (tech stack) deyil, biznes modeli dəyər yaradır.

Yanaşmanın Müsbət Tərəfləri:

• İfrat Dərəcədə Aşağı Maya Dəyəri: Aylıq DevOps, konteyner və verilənlər bazası xərcləri minimuma enir.
• Asan Baxım (Maintainability): Asılılıqların (vendor paketləri, npm modulları) olmaması sistemin illərlə yenilənmə tələb etmədən stabil işləməsinə şərait yaradır.
• Daşına Bilmə (Portability): Layihəni istənilən ən ucuz cPanel/DirectAdmin hostinqə bir neçə dəqiqə ərzində köçürmək mümkündür.

Yanaşmanın Zəif Nöqtələri və Limitləri:

• Trafik Asılılığı: Sayta ziyarətçi gəlmədikdə “pseudo-cron” mexanizmi dayanır. Heç kim sayta girmirsə, arxa plan işləri icra olunmur (bunun qarşısını UptimeRobot kimi pulsuz xarici monitorinq servislərindən hər 5 dəqiqədən bir HTTP sorğusu ataraq almaq olar).
• Miqyaslama (Scalability) Tavanı: Sistem eyni anda on minlərlə paralel müraciət almağa başladıqda, MariaDB üzərindəki tranzaksiya kilidləri (row locking) darboğaz (bottleneck) yarada bilər.

Nəticə

Kimusta-nın arxitekturası texniki icmaya sübut edir ki, düzgün proqramlaşdırma prinsipləri, verilənlər bazasının optimizasiyası və resurslardan qənaətli istifadə ən mürəkkəb bulud infrastrukturlarından daha effektiv ola bilər. Xüsusilə gəlir əldə etməyə başlayanadək və ya məhdud büdcə şəraitində “Köhnə Məktəb” PHP həlləri hələ də bazarda ən güclü rəqabət üstünlüklərindən biridir.