Soroban Verilerini PHP ile Geleneksel Veritabanlarına Nasıl Senkronize Edebiliriz?

Blockchain teknolojilerinin yükselişiyle birlikte, merkeziyetsiz uygulamalar (dApps) ve akıllı sözleşmeler hayatımızın her alanına girmeye başladı. Ancak bu teknolojilerin getirdiği yeniliklerle birlikte, geleneksel yazılım geliştirme yaklaşımlarımızla entegrasyon konusunda bazı zorluklar da ortaya çıkıyor. Özellikle Stellar ekosisteminde yeni nesil akıllı sözleşmeler platformu olan Soroban’dan gelen verileri, hızlı sorgulanabilirlik ve karmaşık analizler için PHP tabanlı web uygulamalarımızın kullandığı geleneksel veritabanlarına senkronize etmek, birçok geliştiricinin karşılaştığı kritik bir ihtiyaçtır. Peki, Soroban’daki dinamik verileri PHP kullanarak geleneksel bir veritabanına sorunsuz bir şekilde nasıl taşıyabiliriz? Bu makale, bu sorunun yanıtlarını adım adım ve pratik örneklerle sunarak, blockchain ile web geliştirme arasındaki köprüyü kurmanıza yardımcı olacak.

Blockchain teknolojileri, şeffaflık, değişmezlik ve merkeziyetsizlik gibi önemli avantajlar sunsa da, geleneksel uygulamaların beklediği hız ve esneklikte veri erişimi konusunda belirli kısıtlamalara sahiptir. Özellikle Soroban gibi akıllı sözleşme platformları üzerinde gerçekleşen binlerce işlem ve üretilen event, doğrudan zincir üzerinden sorgulandığında performans darboğazlarına yol açabilir. Geleneksel veritabanları (SQL veya NoSQL), karmaşık sorgulama yetenekleri, indeksleme mekanizmaları ve binlerce eş zamanlı isteği işleme kapasiteleri sayesinde web uygulamaları için vazgeçilmezdir. İşte tam da bu noktada, Soroban’dan gelen verileri geleneksel bir veritabanına senkronize etmek bir zorunluluk haline gelir.

Öncelikle, kullanıcı deneyimi açısından düşünelim. Bir blockchain uygulamasının, her veri talebi için blok zincirini taramasını beklemek, modern web standartlarının çok gerisinde kalır. Bir kullanıcının kendi işlemlerini veya cüzdan bakiyesini anında görmesini sağlamak için hızlı erişime ihtiyaç duyarız. İkincisi, karmaşık veri analizi ve raporlama yetenekleri. Blockchain üzerinde depolanan ham veriler genellikle yapılandırılmamış veya yarı yapılandırılmış formattadır. Bu verileri belirli kriterlere göre filtrelemek, gruplamak veya farklı tablolarla birleştirmek, geleneksel bir ilişkisel veritabanında çok daha kolay ve performanslıdır. Ayrıca, zincir üstü veriler genellikle yalnızca uygulamanın temel iş mantığını içerir; kullanıcı profilleri, ayarlar veya diğer merkezi sistemlerle entegrasyon için gereken ek veriler, geleneksel veritabanlarında saklanır. Bu nedenle, Soroban’daki akıllı sözleşme eventlerini dinleyerek, bu eventlerden türetilen anlamlı verileri geleneksel bir veritabanına aktarmak, sadece performansı artırmakla kalmaz, aynı zamanda daha zengin ve işlevsel uygulamalar geliştirmemize olanak tanır. PHP ise, güçlü veritabanı entegrasyon yetenekleri ve geniş kütüphane ekosistemi sayesinde bu senkronizasyon katmanını inşa etmek için ideal bir adaydır.

Soroban, PHP ve Veritabanı Senkronizasyonu Nedir?

Bu karmaşık konuya dalmadan önce, temel bileşenleri anlamak faydalı olacaktır. Soroban, Stellar blockchain üzerinde çalışan, Rust tabanlı bir akıllı sözleşme platformudur. Geliştiricilerin yüksek performanslı ve güvenli merkeziyetsiz uygulamalar (dApps) oluşturmasına olanak tanır. Soroban üzerindeki akıllı sözleşmeler, belirli eylemler gerçekleştirdiğinde ‘event’ adı verilen olayları yayabilir. Örneğin, bir token transfer edildiğinde veya bir NFT basıldığında (mint edildiğinde) ilgili bir event yayınlanır. Bu eventler, sözleşmenin dış dünyayla iletişim kurma ve durum değişikliklerini bildirme mekanizmasıdır.

Diğer yandan PHP, sunucu tarafında çalışan, geniş bir kullanıcı tabanına ve zengin bir ekosisteme sahip popüler bir programlama dilidir. Web uygulamaları geliştirmek, API’ler oluşturmak ve veritabanlarıyla etkileşim kurmak için yaygın olarak kullanılır. PHP’nin veritabanı abstraction katmanları (PDO) ve ORM (Object-Relational Mapping) kütüphaneleri (örneğin Laravel’in Eloquent’i veya Doctrine), veritabanı işlemlerini oldukça kolaylaştırır. Senkronizasyon sürecinde PHP, Soroban’dan gelen eventleri dinleyecek, işleyecek ve bu verileri yapılandırılmış bir şekilde bir veritabanına kaydedecektir. Bu, uygulamanızın blockchain’deki değişmez verilerle güncel kalmasını sağlarken, aynı zamanda hızlı sorgulama ve karmaşık analiz yetenekleri sunar.

Veritabanı senkronizasyonu ise, blockchain üzerinde gerçekleşen belirli olayları (eventleri) veya durum değişikliklerini izleyerek, bu bilgileri geleneksel bir veritabanına aktarma ve orada sürekli güncel tutma sürecidir. Bu süreç, blok zincirindeki verinin bir kopyasını veya türetilmiş bir versiyonunu off-chain (zincir dışı) olarak saklamak anlamına gelir. Bu, özellikle karmaşık sorgular çalıştırılması gereken durumlar, kullanıcı arayüzlerinin anında veri sunması gereken anlar ve raporlama/analiz ihtiyaçları için hayati önem taşır. Soroban ile PHP arasındaki senkronizasyon, bir ‘dinleyici’ (listener) görevi gören PHP uygulamasının, Soroban ağındaki akıllı sözleşme eventlerini sürekli olarak takip etmesi ve bu eventler tetiklendiğinde ilgili verileri kendi veritabanına işlemesi prensibine dayanır. Bu sayede, blockchain’in gücünden faydalanırken, geleneksel veritabanlarının esneklik ve performans avantajlarını da korumuş oluruz.

Senkronizasyon Mimarisi ve Stratejileri: Soroban Verilerini Nasıl İzleyebilir ve Yakalayabiliriz?

Soroban’dan gelen eventleri etkili bir şekilde yakalayıp geleneksel bir veritabanına senkronize etmek için sağlam bir mimari ve stratejiye ihtiyacımız var. Temel olarak, bu süreç bir “event dinleyici” mekanizması etrafında döner. Soroban akıllı sözleşmeleri, belirli eylemler (token transferi, NFT basımı vb.) gerçekleştiğinde loglar veya eventler aracılığıyla dış dünyaya bildirimde bulunur. Bu bildirimleri yakalamak, senkronizasyonun ilk ve en kritik adımıdır. İki ana strateji bulunmaktadır: Polling (sorgulama) ve Webhook’lar (eğer Soroban ekosistemi tarafından destekleniyorsa veya bir aracı katman oluşturulabiliyorsa).

Polling Stratejisi: Blok Zincirini Düzenli Sorgulama

Polling, PHP uygulamanızın belirli aralıklarla (örneğin her 10 saniyede bir) Soroban ağındaki RPC (Remote Procedure Call) veya Stellar Horizon API’sini sorgulayarak yeni eventleri kontrol etmesidir. Bu yaklaşım basit kurulumuyla öne çıkar:

1. Sorgulama Aralığı: PHP betiğiniz, önceden belirlenmiş bir zaman aralığında çalışacak şekilde ayarlanır (cron job vb.).
2. Son İşlenen Blok/Event Kimliği: Her sorgulamada, en son işlediğiniz blok numarasını veya event ID’sini saklarsınız. Bu, aynı eventleri tekrar tekrar işlemeyi önler.
3. Yeni Eventleri Çekme: Soroban API’sına son işlenen ID’den sonraki tüm eventleri getirmesi için bir istek gönderilir.
4. Event İşleme: Gelen eventler ayrıştırılır, ilgili veriler çıkarılır ve veritabanına kaydedilmek üzere hazırlanır.

Polling, özellikle düşük frekanslı eventler için basit ve etkili bir çözümdür. Ancak yüksek frekanslı eventlerde veya gerçek zamanlıya yakın senkronizasyon gerektiren durumlarda gecikmelere yol açabilir ve API üzerinde gereksiz yük oluşturabilir.

Webhook veya Push Bildirimleri (Gelişmiş Senaryolar): Anında Geri Bildirim

Webhook’lar, bir olay gerçekleştiğinde (bu durumda Soroban’da bir event) bir sunucu tarafından tanımlanan bir URL’ye otomatik olarak bir HTTP POST isteği gönderme prensibine dayanır. Bu, anında bildirim ve daha verimli bir senkronizasyon sağlar. Soroban’ın kendisi doğrudan gelişmiş webhook yetenekleri sunmasa da, bu tür bir mekanizma bir aracı hizmet veya özel bir indeksleme katmanı oluşturularak taklit edilebilir. Örneğin, özel bir hizmet, Soroban eventlerini dinleyip, bu eventleri ayrıştırıp önceden tanımlanmış PHP endpoint’inize bir POST isteği gönderebilir.

1. Event Dinleyici Servis: Bir Sunucu (Python, Node.js veya başka bir PHP servisi), Soroban ağını sürekli dinler.
2. Event Tetikleyicisi: Yeni bir Soroban event’i tespit edildiğinde, bu servis PHP uygulamanızın belirli bir URL’sine (webhook endpoint) bir HTTP POST isteği gönderir.
3. PHP Webhook Endpoint: PHP uygulamanızdaki bu endpoint, gelen isteği alır, event verilerini işler ve veritabanına kaydeder.

Bu yöntem, daha düşük gecikme ve daha verimli kaynak kullanımı sunar ancak ek bir “dinleyici/tetikleyici” servisinin kurulmasını ve bakımını gerektirir.

Her iki durumda da, temel mimari bir Listener (Dinleyici), bir Processor (İşleyici) ve bir Database (Veritabanı) üçlüsünden oluşur. Listener Soroban eventlerini yakalar, Processor bu eventleri anlamlı verilere dönüştürür ve Database bu verileri kalıcı olarak saklar. Bu süreçte veri bütünlüğünü ve tekilliği sağlamak kritik öneme sahiptir. Aynı event’in birden fazla kez işlenmesini önlemek için her event’in benzersiz bir kimliğe sahip olduğunu ve bu kimliğin veritabanında kontrol edildiğini varsaymalıyız. Bu sayede, senkronizasyon işlemleri sırasında yaşanabilecek olası ağ hatalarına veya yeniden denemelere karşı dayanıklılık kazanırız. Genel olarak, basit uygulamalar için polling yeterli olabilirken, yüksek ölçekli ve gerçek zamanlıya yakın senkronizasyon gerektiren projelerde webhook benzeri bir yaklaşımı düşürmek daha mantıklı olacaktır.

PHP ile Soroban Eventlerini Dinleme ve İşleme: Adım Adım Entegrasyon Rehberi

PHP ile Soroban eventlerini dinlemek ve işlemek için, öncelikle Soroban ağına erişim sağlayan bir yol bulmalıyız. Stellar Horizon API, genellikle Stellar ağındaki bilgilere erişim için kullanılırken, Soroban için doğrudan bir RPC endpoint’i veya özel bir indeksleyici hizmeti üzerinden iletişim kurmak daha yaygındır. Bu örnekte, Soroban RPC endpoint’ine HTTP istekleri göndererek eventleri çekeceğiz. Bunun için PHP’de popüler bir HTTP istemci kütüphanesi olan Guzzle’ı kullanabiliriz.

Öncelikle, projenize Guzzle’ı Composer aracılığıyla dahil etmelisiniz:

composer require guzzlehttp/guzzle

Daha sonra, Soroban RPC endpoint'ini hedefleyerek belirli bir blok aralığındaki veya belirli bir sözleşmeye ait eventleri sorgulayabiliriz. Genellikle getEvents RPC metodunu kullanırız. İşte temel bir PHP betiği ile bu işlemi nasıl yapabileceğinizi gösteren bir örnek:

 $sorobanRpcUrl]);

    // Sonsuz döngü içinde eventleri sürekli dinleyelim
    while (true) {
        echo "Eventler dinleniyor... Son işlenen blok: " . $lastProcessedLedger . PHP_EOL;

        // RPC isteği için parametreler
        // getEvents metodu genellikle bir 'startLedger' ve 'filters' parametresi alır.
        $payload = [
            'jsonrpc' => '2.0',
            'id'      => 1,
            'method'  => 'getEvents',
            'params'  => [
                'startLedger' => $lastProcessedLedger + 1, // Bir sonraki bloktan itibaren
                'filters'     => [
                    [
                        'type'       => 'contract',
                        // Eğer belirli bir sözleşmenin eventlerini dinlemek istiyorsanız
                        // 'contractId' => 'CONTRACT_ID_BURAYA_GELECEK',
                        // Tüm eventleri dinlemek için 'contractId' filtresini kaldırabilirsiniz.
                    ]
                ],
                'pagination' => [
                    'limit' => 10, // Her seferinde en fazla 10 event çek
                ]
            ]
        ];

        $response = $client->post('', [
            'json' => $payload
        ]);

        $result = json_decode($response->getBody()->getContents(), true);

        if (isset($result['error'])) {
            echo "RPC Hatası: " . $result['error']['message'] . PHP_EOL;
            sleep(5); // Hata durumunda bekle
            continue;
        }

        if (empty($result['result']['events'])) {
            echo "Yeni event bulunamadı. " . PHP_EOL;
            sleep(10); // Yeni event yoksa 10 saniye bekle
            continue;
        }

        foreach ($result['result']['events'] as $event) {
            echo "Yeni Event Alındı: " . PHP_EOL;
            echo "  Ledger: " . $event['ledger'] . PHP_EOL;
            echo "  Contract ID: " . $event['contractId'] . PHP_EOL;
            echo "  Topic: " . json_encode($event['topic']) . PHP_EOL;
            echo "  Data: " . $event['data'] . PHP_EOL;
            echo "------------------------------------" . PHP_EOL;

            // Burada event verilerini ayrıştırma ve veritabanına kaydetme mantığı gelecek.
            // Örnek: saveEventToDatabase($event);

            // En son işlenen bloğu güncelle
            $lastProcessedLedger = max($lastProcessedLedger, $event['ledger']);
        }

        // Bir sonraki sorgulamadan önce biraz bekle
        sleep(5);

    }

} catch (GuzzleException $e) {
    echo "HTTP İsteği Hatası: " . $e->getMessage() . PHP_EOL;
} catch (Exception $e) {
    echo "Genel Hata: " . $e->getMessage() . PHP_EOL;
}

// saveEventToDatabase fonksiyonu örnek
function saveEventToDatabase(array $event) {
    // Veritabanı bağlantısı burada kurulmalı (PDO veya ORM ile)
    // Örnek olarak:
    // $pdo = new PDO('mysql:host=localhost;dbname=soroban_db', 'user', 'password');
    // $stmt = $pdo->prepare("INSERT INTO events (ledger, contract_id, topic, data) VALUES (?, ?, ?, ?)");
    // $stmt->execute([$event['ledger'], $event['contractId'], json_encode($event['topic']), $event['data']]);
    echo "Event veritabanına kaydedildi: " . $event['ledger'] . PHP_EOL;
}


Bu kod bloğu, Soroban RPC endpoint'ine düzenli olarak getEvents isteği gönderen basit bir polling mekanizmasını gösterir. lastProcessedLedger değişkeni, aynı eventleri tekrar işlemeyi önlemek için kritik öneme sahiptir ve gerçek bir uygulamada kalıcı olarak (bir veritabanında veya bir Redis anahtarında) saklanmalıdır. Gelen eventlerin topic ve data alanları, akıllı sözleşmenin mantığına bağlı olarak ayrıştırılmalıdır. data alanı genellikle base64 encoded ve XDR formatında olabilir, bu da özel bir çözümleme gerektirebilir. Bu kısımları kendi akıllı sözleşmenizin yapısına göre özelleştirmelisiniz. Bu PHP betiği, bir CLI aracı olarak çalıştırılabilir ve bir cron job ile düzenli aralıklarla tetiklenebilir veya sürekli çalışan bir daemon olarak yapılandırılabilir.
Veritabanı Tasarımı ve Veri Modeli: Soroban Akıllı Sözleşme Verileri Nasıl Saklanmalı?
Soroban'dan gelen event verilerini geleneksel bir veritabanına aktarmak için sağlam ve ölçeklenebilir bir veri modeline ihtiyacımız var. Veritabanı tasarımımız, hem Soroban akıllı sözleşmesinin yapısını yansıtmalı hem de uygulamamızın sorgulama ihtiyaçlarını karşılamalıdır. Bir örnek üzerinden gidelim: diyelim ki bir NFT pazar yeri akıllı sözleşmeniz var. Bu sözleşme NFT basımı (mint), transferi ve satış eventleri yayınlıyor. Bu eventlerden türetilen verileri bir PostgreSQL veya MySQL veritabanında nasıl saklayacağımızı inceleyelim.
Örnek Senaryo: NFT Pazar Yeri Sözleşmesi
NFT pazar yeri sözleşmemiz şu eventleri yayınlayabilir:

mint: Bir NFT basıldığında (tokenId, owner, tokenUri)
transfer: Bir NFT transfer edildiğinde (from, to, tokenId)
sale: Bir NFT satıldığında (tokenId, seller, buyer, price, currency)

Veritabanı Seçimi: SQL mi, NoSQL mi?
Çoğu durumda, Soroban'dan gelen yapılandırılmış veya yarı yapılandırılmış verileri saklamak için ilişkisel veritabanları (SQL) oldukça uygundur. Özellikle karmaşık ilişkiler, güçlü sorgu yetenekleri ve veri bütünlüğü garantileri arıyorsanız, PostgreSQL veya MySQL tercih edilebilir. Eğer event verileri çok dinamik ve esnek bir yapıya sahipse, veya çok büyük hacimli verileri hızlı bir şekilde indekslemeniz gerekiyorsa MongoDB gibi NoSQL veritabanları da bir seçenek olabilir. Bu makalede, daha yaygın olduğu için SQL (PostgreSQL/MySQL) üzerine odaklanacağız.
Örnek Tablo Yapıları
NFT pazar yeri senaryomuz için aşağıdaki gibi tablolar tasarlayabiliriz:

events Tablosu: Genel event loglarını saklamak için birincil tablo. Bu tablo, Soroban'dan gelen her ham event'i kaydeder.



CREATE TABLE events (
    id BIGSERIAL PRIMARY KEY,
    ledger_sequence INT NOT NULL,
    transaction_hash VARCHAR(64) NOT NULL,
    contract_id VARCHAR(64) NOT NULL,
    event_type VARCHAR(50) NOT NULL, -- 'contract' gibi
    topic JSONB NOT NULL, -- Eventin konuları (örneğin ["mint", "token_id"])
    data TEXT NOT NULL, -- Ham event verisi (base64 encoded)
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT unique_event_tx_id UNIQUE (transaction_hash, event_type, topic, data) -- Yinelenen eventleri önlemek için
);


Bu tablo, her bir Soroban event'ini orijinal haliyle kaydetmemize olanak tanır. transaction_hash ve diğer alanların birleşimiyle benzersizlik sağlayarak, aynı event'in tekrar işlenmesini önleriz. topic alanını JSONB (PostgreSQL) veya JSON (MySQL) olarak tutmak, dinamik topic yapılarına uyum sağlar.

nfts Tablosu: Basılan her bir NFT'nin temel bilgilerini saklar.



CREATE TABLE nfts (
    id BIGSERIAL PRIMARY KEY,
    token_id VARCHAR(255) UNIQUE NOT NULL, -- Blockchain'deki NFT ID'si
    owner_address VARCHAR(64) NOT NULL,
    token_uri TEXT, -- NFT metadata URI'si
    minted_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    last_updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);



nft_transfers Tablosu: NFT transfer eventlerini kaydeder.



CREATE TABLE nft_transfers (
    id BIGSERIAL PRIMARY KEY,
    nft_id BIGINT NOT NULL REFERENCES nfts(id),
    from_address VARCHAR(64) NOT NULL,
    to_address VARCHAR(64) NOT NULL,
    transfer_time TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);



nft_sales Tablosu: NFT satış eventlerini kaydeder.



CREATE TABLE nft_sales (
    id BIGSERIAL PRIMARY KEY,
    nft_id BIGINT NOT NULL REFERENCES nfts(id),
    seller_address VARCHAR(64) NOT NULL,
    buyer_address VARCHAR(64) NOT NULL,
    price NUMERIC(20, 7) NOT NULL,
    currency_code VARCHAR(10) NOT NULL,
    sale_time TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);


Bu yapı, ham event verilerini tutmanın yanı sıra, bu eventlerden türetilen anlamlı iş verilerini (NFT'ler, transferler, satışlar) ilişkisel bir şekilde saklamamızı sağlar. Örneğin, bir mint event'i geldiğinde nfts tablosuna yeni bir kayıt eklenir. Bir transfer event'i geldiğinde, hem nft_transfers tablosuna bir kayıt eklenir hem de ilgili nfts kaydının owner_address alanı güncellenir. Bu, veri modelini güncel ve tutarlı tutar.

  Uzman İpucu: Event verileri genellikle XDR formatında ve base64 kodlu gelir. PHP tarafında bunları okumak için Stellar SDK veya özel XDR çözümleyici kütüphaneleri kullanmanız gerekebilir. PHP'de bir XDR kütüphanesi bulunmuyorsa, Python/Node.js gibi dillerde yazılmış bir mikroservis aracılığıyla bu dönüşümü yapıp PHP'ye temiz veri gönderebilirsiniz.

Veritabanına Kayıt ve Güncelleme İşlemleri: PHP ile Güvenli ve Etkin Veri Yönetimi
Soroban'dan gelen eventleri başarıyla yakalayıp ayrıştırdıktan sonra, sıra bu verileri geleneksel veritabanımıza kaydetmeye gelir. Bu adımda, veri bütünlüğünü sağlamak, aynı event'in birden fazla kez işlenmesini önlemek (idempotency) ve olası hataları yönetmek kritik öneme sahiptir. PHP'de veritabanı etkileşimi için PDO (PHP Data Objects) veya bir ORM (Object-Relational Mapping) kütüphanesi (Laravel için Eloquent, Symfony için Doctrine gibi) kullanabiliriz. ORM'ler, veritabanı işlemlerini nesne odaklı bir yaklaşımla daha okunabilir ve yönetilebilir hale getirir.
Idempotency (Tekrarlanan İşlemleri Önleme)
Senkronizasyon süreçlerinde ağ hataları, sunucu kesintileri veya yeniden denemeler nedeniyle aynı event'in birden fazla kez işlenme riski vardır. Idempotency, bir işlemin birden fazla kez yapılsa bile sistemin durumunun yalnızca bir kez etkilenmesini sağlar. Bunu sağlamak için:

Her Soroban event'inin benzersiz bir tanımlayıcısını (transaction hash, event index, ledger sequence gibi) veritabanında saklayın.
Veritabanı tablolarınızda, bu benzersiz tanımlayıcılar üzerinde UNIQUE kısıtlamaları (constraint) kullanın.
Bir event'i kaydetmeden önce, bu event'in zaten mevcut olup olmadığını kontrol edin.

PDO ile Veritabanı Kayıt Örneği
Aşağıdaki örnek, PHP PDO kullanarak bir NFT 'mint' event'ini nasıl işleyip nfts ve events tablolarına kaydedeceğinizi gösterir. Bu örnekte, parseSorobanEventData fonksiyonunun Soroban event'inin data ve topic alanlarını ayrıştırıp anlamlı verilere dönüştürdüğünü varsayıyoruz.


 'mint',
            'token_id'  => 'nft_' . bin2hex(random_bytes(8)), // Örnek ID
            'owner'     => 'GA...' . substr(md5($decodedData), 0, 5) . '...', // Örnek adres
            'token_uri' => 'https://example.com/nft/' . bin2hex(random_bytes(10)) . '.json'
        ];
    }
    // Diğer event türleri için benzer ayrıştırma mantığı
    return ['type' => 'unknown', 'raw_data' => $sorobanEvent['data']];
}

function processAndSaveSorobanEvent(array $sorobanEvent, PDO $pdo)
{
    // Event zaten işlenmiş mi kontrol et (idempotency)
    // Bu kontrol, events tablosundaki unique_event_tx_id kısıtlaması ile de sağlanabilir.
    $stmt = $pdo->prepare("SELECT COUNT(*) FROM events WHERE transaction_hash = ? AND ledger_sequence = ? AND event_type = ?");
    $stmt->execute([$sorobanEvent['txHash'], $sorobanEvent['ledger'], $sorobanEvent['type']]); // 'type' burada Soroban event'inin kendi tipi (contract, system)
    if ($stmt->fetchColumn() > 0) {
        echo "Event zaten işlenmiş: " . $sorobanEvent['txHash'] . PHP_EOL;
        return;
    }

    // Ham event'i 'events' tablosuna kaydet
    try {
        $stmt = $pdo->prepare("INSERT INTO events (ledger_sequence, transaction_hash, contract_id, event_type, topic, data) VALUES (?, ?, ?, ?, ?, ?)");
        $stmt->execute([
            $sorobanEvent['ledger'],
            $sorobanEvent['txHash'],
            $sorobanEvent['contractId'],
            $sorobanEvent['type'], // Orjinal event tipi (contract, system)
            json_encode($sorobanEvent['topic']),
            $sorobanEvent['data']
        ]);
        $eventId = $pdo->lastInsertId(); // Kaydedilen event'in ID'si
        echo "Ham event kaydedildi (ID: {$eventId})." . PHP_EOL;
    } catch (PDOException $e) {
        // Unique constraint hatası olabilir, bu da idempotentcy'yi sağlar
        if ($e->getCode() == '23505' || $e->getCode() == '23000') { // PostgreSQL veya MySQL unique violation
            echo "Event zaten mevcut (muhtemelen aynı anda işlendi): " . $sorobanEvent['txHash'] . PHP_EOL;
            return;
        }
        throw $e; // Diğer hataları yeniden fırlat
    }


    // Event verilerini ayrıştır
    $parsedData = parseSorobanEventData($sorobanEvent);

    // Ayrıştırılan verilere göre ilgili tablolara kaydet/güncelle
    if ($parsedData['type'] === 'mint') {
        // NFT mint event'i
        $stmt = $pdo->prepare("INSERT INTO nfts (token_id, owner_address, token_uri) VALUES (?, ?, ?)");
        $stmt->execute([
            $parsedData['token_id'],
            $parsedData['owner'],
            $parsedData['token_uri']
        ]);
        echo "Yeni NFT mint edildi: " . $parsedData['token_id'] . PHP_EOL;

    } elseif ($parsedData['type'] === 'transfer') {
        // NFT transfer event'i
        // Önce NFT'yi bulalım
        $stmt = $pdo->prepare("SELECT id FROM nfts WHERE token_id = ?");
        $stmt->execute([$parsedData['token_id']]);
        $nftId = $stmt->fetchColumn();

        if ($nftId) {
            // Transfer kaydını ekle
            $stmt = $pdo->prepare("INSERT INTO nft_transfers (nft_id, from_address, to_address) VALUES (?, ?, ?)");
            $stmt->execute([
                $nftId,
                $parsedData['from'],
                $parsedData['to']
            ]);

            // NFT'nin sahibini güncelle
            $stmt = $pdo->prepare("UPDATE nfts SET owner_address = ?, last_updated_at = NOW() WHERE id = ?");
            $stmt->execute([$parsedData['to'], $nftId]);
            echo "NFT transfer edildi ve sahip güncellendi: " . $parsedData['token_id'] . PHP_EOL;
        } else {
            echo "Hata: Transfer edilen NFT bulunamadı: " . $parsedData['token_id'] . PHP_EOL;
        }
    }
    // Diğer event türleri (sale vb.) için benzer mantık eklenebilir.
}

// Veritabanı bağlantısı
try {
    $pdo = new PDO('pgsql:host=localhost;dbname=soroban_nft_db', 'user', 'password'); // PostgreSQL örneği
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);

    // Örnek bir Soroban event nesnesi (gerçek RPC'den geldiğini varsayalım)
    $sampleSorobanMintEvent = [
        'txHash'     => '0x123abc...', // Örnek işlem hash'i
        'ledger'     => 1234567,       // Örnek blok numarası
        'contractId' => 'CONTRACT_ID_ABC',
        'type'       => 'contract',    // Soroban event tipi
        'topic'      => ['AAAAAQ==', 'mint'], // Base64 encoded 'mint' string
        'data'       => 'AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=' // Örnek base64 data
    ];

    processAndSaveSorobanEvent($sampleSorobanMintEvent, $pdo);

} catch (PDOException $e) {
    echo "Veritabanı bağlantı veya işlem hatası: " . $e->getMessage() . PHP_EOL;
} catch (Exception $e) {
    echo "Genel Hata: " . $e->getMessage() . PHP_EOL;
}


Hata Yönetimi ve Yeniden Deneme Mekanizmaları
Senkronizasyon süreci, ağ kesintileri, veritabanı bağlantı sorunları veya geçersiz event verileri gibi çeşitli hatalarla karşılaşabilir. Bu durumlar için sağlam bir hata yönetimi stratejisi geliştirmek önemlidir:

Try-Catch Blokları: Veritabanı işlemleri ve API çağrıları etrafında try-catch blokları kullanarak istisnaları yakalayın.
Loglama: Her hatayı detaylı bir şekilde loglayın (hat_türü, zaman damgası, event verisi, stack trace). Bu, sorun giderme için hayati öneme sahiptir. Monolog gibi kütüphaneler kullanabilirsiniz.
Yeniden Deneme Mekanizmaları: Geçici ağ hataları için, belirli bir gecikmeyle (exponential backoff ile) işlemleri birkaç kez yeniden denemeyi düşünün.
Hatalı Event Kuyruğu (Dead Letter Queue): Kalıcı olarak işlenemeyen (örneğin, veri formatı hatalı olan) eventleri ayrı bir "hatalı event kuyruğuna" veya tablosuna taşıyın. Bu, ana senkronizasyon akışını tıkamasını önler ve daha sonra manuel olarak incelenebilir.

Etkin hata yönetimi ve idempotency, senkronizasyon sisteminizin güvenilirliğini ve veri bütünlüğünü büyük ölçüde artırır. Bu sayede, Soroban'dan gelen veriler, PHP uygulamanızın gereksinimlerine uygun, tutarlı ve erişilebilir bir şekilde veritabanınızda yerini alır.
Gerçek Dünya Senaryosu: Bir NFT Pazar Yeri Veri Senkronizasyonu
Teorik bilgileri ve teknik adımları öğrendikten sonra, gerçek dünyadan bir senaryo ile konuyu pekiştirelim: Bir NFT Pazar Yeri. Bu senaryoda, kullanıcılar NFT'leri basabilir (mint), birbirlerine transfer edebilir ve belirledikleri fiyatlarla satabilirler. Tüm bu işlemler Soroban akıllı sözleşmeleri üzerinde gerçekleşirken, pazar yerinin web arayüzü (PHP ile geliştirilmiş) bu verilere hızlı ve etkin bir şekilde erişmek zorundadır. İşte bu noktada, Soroban eventlerini PHP ile veritabanına senkronize etme mimarimiz devreye giriyor.
Senaryo Tanıtımı ve İhtiyaçlar
Kurgusal NFT Pazar Yerimiz "SorobanArt" aşağıdaki özelliklere sahip:

Kullanıcılar cüzdanlarıyla bağlanır ve kendi NFT koleksiyonlarını görür.
NFT'ler basılabilir (mint edilebilir) ve pazar yerinde listelenebilir.
NFT'ler diğer kullanıcılara transfer edilebilir.
NFT'ler belirlenen bir fiyattan satılabilir.
Pazar yerinde tüm NFT'leri, satış geçmişini ve aktif listelemeleri gösteren sayfalar bulunur.

Bu özellikler, blockchain'deki veriye dayanır ancak doğrudan zincir üzerinden sorgulamak performans, maliyet ve kullanıcı deneyimi açısından verimsizdir. Bu yüzden bir senkronizasyon katmanına ihtiyacımız var.
Eventlerin Yakalanması ve Veritabanına İşlenmesi
SorobanArt'taki akıllı sözleşme, mint, transfer ve sale gibi farklı event'ler yayar. PHP ile yazdığımız event dinleyici (önceki bölümlerde gösterilen polling mekanizması gibi), bu eventleri yakalar. Her bir event türü için, veriler ayrıştırılır ve daha önce tasarladığımız veritabanı tablolarına (nfts, nft_transfers, nft_sales) kaydedilir veya güncellenir.
Örnek Event Akışı ve Veritabanı Etkileşimi:

NFT Basımı (Mint Event):

Bir kullanıcı NFT basımı işlemi başlatır. Soroban akıllı sözleşmesi mint(token_id, owner_address, token_uri) event'ini yayınlar.
PHP dinleyici bu event'i yakalar.
token_id, owner_address ve token_uri verileri ayrıştırılır.
nfts tablosuna yeni bir kayıt eklenir (token_id, owner_address, token_uri ile).
Genel events tablosuna da ham event loglanır.


NFT Transferi (Transfer Event):

Bir kullanıcı NFT'sini başka bir adrese transfer eder. Sözleşme transfer(from_address, to_address, token_id) event'ini yayınlar.
PHP dinleyici event'i yakalar.
nfts tablosundaki ilgili token_id kaydının owner_address alanı yeni sahibin adresiyle güncellenir.
nft_transfers tablosuna yeni bir transfer kaydı eklenir (nft_id, from_address, to_address ile).
Genel events tablosuna da ham event loglanır.


NFT Satışı (Sale Event):

Bir kullanıcı NFT'sini pazar yerinde listeler ve başka bir kullanıcı satın alır. Sözleşme sale(token_id, seller_address, buyer_address, price, currency) event'ini yayınlar.
PHP dinleyici event'i yakalar.
nft_sales tablosuna yeni bir satış kaydı eklenir (nft_id, seller_address, buyer_address, price, currency ile).
NFT'nin sahibini güncellemek için nfts tablosundaki owner_address alanı güncellenir (seller'dan buyer'a).
Genel events tablosuna da ham event loglanır.



Kullanıcı Arayüzünde Verilerin Gösterilmesi (PHP Laravel/Symfony Örneği)
Tüm bu veriler geleneksel veritabanımızda saklandığı için, PHP tabanlı bir framework (Laravel veya Symfony gibi) kullanarak kolayca görüntülenebilir. Örneğin, bir kullanıcının kendi NFT koleksiyonunu görüntülemek için basit bir sorgu yeterli olacaktır:


// Laravel Controller örneği
namespace App\Http\Controllers;

use App\Models\Nft; // Eloquent modeli
use Illuminate\Http\Request;

class NftController extends Controller
{
    public function getUserNfts(Request $request, string $userAddress)
    {
        // Veritabanından kullanıcının sahip olduğu NFT'leri çek
        $nfts = Nft::where('owner_address', $userAddress)->get();

        return view('user.nfts', ['nfts' => $nfts, 'userAddress' => $userAddress]);
    }

    public function getAllListings()
    {
        // Aktif satış listelemelerini çek (örneğin, nft_sales tablosunda 'is_active' alanı varsayarak)
        $listings = NftSale::with('nft')->where('is_active', true)->get();

        return view('marketplace.listings', ['listings' => $listings]);
    }
}


Bu şekilde, pahalı ve yavaş blockchain sorgularına gerek kalmadan, hızlı ve etkileşimli bir kullanıcı deneyimi sunabiliriz. PHP uygulamanız, anında veritabanından gerekli bilgileri çekerek sayfa yükleme sürelerini optimize eder ve gelişmiş filtreleme, sıralama gibi özellikler sunabilir.
Performans ve Ölçeklenebilirlik Düşünceleri
Büyük ölçekli bir pazar yerinde milyonlarca NFT ve yüz binlerce işlem olabilir. Bu durumda, senkronizasyon sürecinin kendisi bir darboğaz haline gelebilir.

İndeksleme: Veritabanı tablolarınızdaki sorgu performansını artırmak için owner_address, token_id, transfer_time gibi sıkça sorgulanan sütunlara uygun indeksler ekleyin.
Asenkron İşleme: Event dinleyiciyi ve veritabanı kayıt işlemlerini asenkron hale getirmek için bir mesaj kuyruğu sistemi (RabbitMQ, Redis Queue veya AWS SQS gibi) kullanabilirsiniz. Dinleyici sadece eventleri kuyruğa atar, ayrı çalışan işçiler (workers) kuyruktaki eventleri çekip veritabanına kaydeder. Bu, yükün dağıtılmasına ve daha yüksek işlem hacmine olanak tanır.
Veri Bütünlüğü: Özellikle transfer ve satış gibi durumlarda, bir NFT'nin birden fazla sahibi veya eş zamanlı satışını önlemek için veritabanı seviyesinde işlem (transaction) kullanarak veri bütünlüğünü garanti altına alın.

Bu senaryo, Soroban'dan gelen blockchain verilerinin PHP uygulamaları tarafından nasıl etkin bir şekilde kullanılabileceğini ve geleneksel veritabanlarının gücüyle nasıl birleşebileceğini somut bir şekilde göstermektedir. Geliştiriciler, bu entegrasyonla hem blockchain'in temel avantajlarından yararlanabilir hem de kullanıcılarına üst düzey bir deneyim sunabilirler.
İleri Düzey Senkronizasyon Teknikleri ve Optimizasyonlar: Büyük Ölçekli Uygulamalar İçin İpuçları
Küçük ve orta ölçekli uygulamalar için basit polling ve doğrudan veritabanı yazma yeterli olabilirken, büyük ölçekli ve yüksek işlem hacmine sahip dApp'ler için daha sofistike senkronizasyon teknikleri ve optimizasyonlar kaçınılmaz hale gelir. Performansı, ölçeklenebilirliği ve veri tutarlılığını artırmak için aşağıdaki ileri düzey yaklaşımları göz önünde bulundurmalıyız.
Kuyruk Sistemleri (Message Queues) Kullanımı
Doğrudan veritabanına yazma, özellikle yoğun event akışı olduğunda veritabanı üzerinde yüksek yük oluşturabilir ve PHP dinleyicisinin eventleri kaçırmasına neden olabilir. Bu senaryolarda, bir mesaj kuyruğu sistemi kullanmak kritik bir optimizasyondur.
Nasıl Çalışır?

Dinleyici (Listener): Soroban eventlerini dinleyen PHP betiği, yakaladığı her event'i doğrudan veritabanına yazmak yerine, bir mesaj kuyruğuna (örneğin RabbitMQ, Redis Queue, Apache Kafka, AWS SQS) gönderir.
İşleyiciler (Workers): Ayrı PHP işleyicileri (worker'lar), kuyruktaki eventleri çeker ve her bir event'i bağımsız olarak veritabanına işler. Bu worker'lar, ihtiyaca göre ölçeklendirilebilir.

Avantajları:

Yük Dengeleme: Event akışı ne kadar yoğun olursa olsun, dinleyici sadece kuyruğa atma işlemini yapar, bu da hızlıdır. İşleme yükü worker'lar arasında dağıtılır.
Hata Toleransı: Bir worker başarısız olursa, event tekrar kuyruğa alınabilir ve başka bir worker tarafından işlenebilir. Bu, veri kaybını önler.
Asenkron İşleme: Veritabanı yazma gibi zaman alıcı işlemler, ana dinleyici sürecini engellemeden arka planda gerçekleştirilir.

Veri Bütünlüğü ve Tutarlılık Garantileri
Blockchain doğası gereği değiştirilemez ve tutarlıdır. Ancak, zincir dışı veritabanımıza senkronize ederken bu tutarlılığı sağlamak bizim sorumluluğumuzdadur.

İşlemler (Transactions): Özellikle birden fazla veritabanı tablosunu etkileyen eventlerde (örneğin NFT transferinde nfts ve nft_transfers tabloları), veritabanı işlemlerini kullanın. Bu, tüm değişikliklerin ya başarılı bir şekilde gerçekleşmesini ya da hiçbirinin gerçekleşmemesini sağlar (ACID özellikleri).
Kilitleme Mekanizmaları: Nadiren de olsa, eş zamanlı worker'lar aynı veriyi güncellemeye çalışabilir. Bu tür çakışmaları önlemek için veritabanı kilitleri veya optimistik kilitleme gibi mekanizmaları değerlendirin.
Checksum/Hash Doğrulaması: Kritik event verileri için, orijinal blockchain verisinin bir hash'ini veritabanınızda saklayın. Daha sonra periyodik olarak bu hash'leri yeniden hesaplayıp blockchain'dekiyle karşılaştırarak veri bütünlüğünü doğrulayabilirsiniz.

Senkronizasyonun Monitörlenmesi ve Loglama
Sistemin sağlıklı çalıştığından emin olmak için kapsamlı monitörleme ve loglama şarttır.

Loglama: Her event işleme adımını, hataları ve uyarıları detaylıca loglayın. Logları merkezi bir log yönetimi sistemine (ELK Stack, Grafana Loki vb.) gönderin.
Metrikler: İşlenen event sayısı, hata oranı, kuyruk boyutu, işlem gecikmesi gibi metrikleri izleyin. Prometheus gibi araçlar ve Grafana ile görselleştirme yapın.
Uyarılar: Belirlenen eşik değerlerinin (örneğin, kuyruk boyutunun çok büyümesi, hata oranının artması) aşılması durumunda otomatik uyarılar (e-posta, Slack vb.) gönderin.

Veri Transformasyonu ve Zenginleştirme (Enrichment)
Soroban eventlerinden gelen ham veriler, kullanıcı arayüzünde doğrudan kullanılabilecek formda olmayabilir.

XDR Çözümleme: Soroban verileri genellikle XDR (External Data Representation) formatında ve base64 kodlu gelir. PHP için bir XDR çözümleyici kütüphanesi (varsa) veya Node.js/Python gibi dillerde yazılmış bir mikroservis aracılığıyla bu verileri okunabilir hale getirin.
Veri Zenginleştirme: Eventlerden gelen contractId veya owner_address gibi bilgilerle, off-chain (zincir dışı) başka veritabanlarından veya API'lerden ek bilgiler (örneğin, sözleşme adı, kullanıcı profili resmi) çekerek veriyi zenginleştirin. Bu zenginleştirilmiş veriyi doğrudan veritabanına kaydederek, frontend'in daha az API çağrısı yapmasını sağlayın.
Türetilmiş Durum: NFT'nin anlık sahibi gibi "türetilmiş durumları" ayrı tablolarda saklayın. Bu, karmaşık join'ler yerine doğrudan sorgularla verilere erişimi hızlandırır.


  Uzman İpucu: Büyük bir geçmiş veri setini senkronize ederken, tek bir süreç yerine paralel çalışan birden fazla worker kullanın. Her worker belirli bir blok aralığını işleyebilir. Bu, ilk senkronizasyon süresini önemli ölçüde kısaltır.

Bu ileri düzey teknikler, Soroban ile PHP senkronizasyonunuzu daha dayanıklı, ölçeklenebilir ve yönetilebilir hale getirerek, blockchain'in dinamik dünyası ile geleneksel web uygulamalarının beklentileri arasında kusursuz bir köprü kurmanızı sağlar.
Sonuç: Soroban-PHP Senkronizasyonunun Geleceği
Blockchain teknolojilerinin, özellikle de Soroban gibi akıllı sözleşme platformlarının sunduğu potansiyel, merkeziyetsiz uygulamaların geleceğini şekillendiriyor. Ancak bu potansiyeli tam anlamıyla ortaya çıkarmak için, blockchain'in sunduğu değişmezlik ve şeffaflık avantajlarını, geleneksel veritabanlarının sunduğu performans ve esneklikle birleştirmek esastır. Bu makalede, Soroban'dan gelen eventleri PHP kullanarak geleneksel bir veritabanına nasıl senkronize edeceğimizi adım adım ele aldık.
Giriş seviyesinden başlayarak, neden bu senkronizasyona ihtiyaç duyduğumuzu, temel kavramları ve mimari stratejileri inceledik. PHP ile Soroban RPC API'sine nasıl bağlanılacağını, eventlerin nasıl dinleneceğini ve ayrıştırılacağını detaylı kod örnekleriyle gösterdik. Ardından, gelen verileri barındırmak için veritabanı tasarım prensiplerini ve güvenli veri kayıt işlemlerini ele aldık. Bir NFT pazar yeri senaryosu üzerinden gerçek dünya uygulamasını somutlaştırdık ve son olarak, büyük ölçekli uygulamalar için kritik olan ileri düzey optimizasyon tekniklerine değindik.
Bu entegrasyon, PHP geliştiricilerine blockchain dünyasına açılan güçlü bir kapı sunuyor. Mevcut PHP becerilerinizi kullanarak, Soroban üzerindeki akıllı sözleşmelerle etkileşim kuran, zengin özelliklere sahip, hızlı ve güvenilir dApp'ler geliştirebilirsiniz. Unutmayın, senkronizasyon süreci devamlılık gerektiren bir iştir; sisteminizin monitörlenmesi, loglanması ve olası hatalara karşı dayanıklı olması kritik öneme sahiptir. Blockchain teknolojileri olgunlaştıkça, bu tür senkronizasyon araçları ve yöntemleri de gelişmeye devam edecektir. Geliştiriciler olarak, bu sürekli evrimi takip ederek sistemlerimizi güncel ve etkin tutmak, geleceğin merkeziyetsiz web'ini inşa etme yolculuğumuzda bize önemli avantajlar sağlayacaktır.
Sıkça Sorulan Sorular (SSS)
1. Soroban eventlerini dinlemek için PHP dışında hangi dilleri kullanabilirim?
Cevap: Soroban RPC API'sine HTTP istekleri gönderebilen herhangi bir programlama dilini kullanabilirsiniz. Python, Node.js (JavaScript/TypeScript), Go ve Rust bu tür işlemleri gerçekleştirmek için oldukça popüler seçeneklerdir. Seçiminiz genellikle ekosistem desteğine, performans gereksinimlerinize ve kendi uzmanlığınıza bağlı olacaktır.
2. Neden Soroban'daki verileri doğrudan okumak yerine veritabanına senkronize etmeliyim?
Cevap: Doğrudan Soroban'dan veri okumak genellikle daha yavaştır, maliyetli olabilir (RPC çağrıları limitli olabilir) ve karmaşık sorgular için uygun değildir. Geleneksel veritabanları ise hızlı indeksleme, karmaşık JOIN işlemleri, gelişmiş filtreleme ve raporlama yetenekleri sunar. Senkronizasyon, kullanıcılarınıza hızlı ve akıcı bir deneyim sunarken, blockchain'in değişmezliğini korumanızı sağlar.
3. Senkronizasyon işlemi sırasında veri kaybını nasıl önleyebilirim?
Cevap: Veri kaybını önlemek için birkaç strateji uygulanmalıdır: 1) Her event için benzersiz bir kimlik kullanarak (işlem hash'i, blok numarası + event indeksi gibi) idempotency (tekrarlanan işlem önleme) sağlayın. 2) Eventleri doğrudan veritabanına yazmak yerine bir mesaj kuyruğuna (RabbitMQ, Redis Queue) atarak asenkron işleme yapın. Bu, dinleyicinin eventleri kaçırmamasını sağlar. 3) Veritabanı işlemleri sırasında (ACID özellikleri olan) transaction'lar kullanın. 4) Hata loglamayı ve yeniden deneme mekanizmalarını uygulayın. 5) Son olarak, işlenemeyen eventler için bir "dead letter queue" (hatalı event kuyruğu) bulundurun.
4. Soroban event verilerini XDR formatından PHP'ye nasıl çevirebilirim?
Cevap: Soroban eventleri genellikle base64 kodlu XDR (External Data Representation) formatındadır. PHP ekosisteminde Stellar/Soroban XDR çözümleyici kütüphaneleri sınırlı olabilir. Bu durumda, ya kendinize özel bir XDR çözümleyici yazmanız ya da Python (xdr-py) veya Node.js (stellar-sdk) gibi daha güçlü XDR kütüphanelerine sahip dillerde küçük bir mikroservis oluşturarak bu dönüşümü yapıp PHP'ye hazır veriyi göndermeniz gerekebilir.
5. Senkronizasyon betiğimi nasıl kalıcı olarak çalıştırabilirim ve yönetimini nasıl yapabilirim?
Cevap: Bir CLI betiği olarak yazdığınız senkronizasyon kodunu kalıcı olarak çalıştırmak için farklı yöntemler mevcuttur:

Cron Job: Belirli aralıklarla (örneğin her 30 saniyede bir) betiği tetikleyebilir. Ancak bu, eventleri "gerçek zamanlıya yakın" işlemek için ideal değildir.
Supervisor/Systemd: Linux sistemlerinde Supervisor veya Systemd gibi süreç yöneticileri kullanarak PHP betiğinizi sürekli çalışan bir daemon olarak yapılandırabilirsiniz. Bu araçlar, betiğiniz çöktüğünde otomatik olarak yeniden başlatılmasını sağlar.
Docker: Betiğinizi bir Docker container'ı içinde çalıştırabilir ve container'ın sağlıklı kalmasını Kubernetes gibi orkestrasyon araçlarıyla yönetebilirsiniz.

Her durumda, betiğinizin doğru loglama ve hata yönetimi mekanizmalarına sahip olması, sorun giderme ve yönetim için hayati öneme sahiptir.