Çoğu kişi için paylaşımlı scooter'lar basit bir mobil uygulama deneyiminden ibaret olsa da, biz mühendisler için bu ekosistem, dağıtık sistemlerin (Distributed Systems) yaşayan en karmaşık örneklerinden biri. Sahadaki binlerce uç noktanın (Edge Device) kararsız ağ koşullarında yönetilmesi, aslında bir yazılım mimarisi meydan okumasıdır. İşin derinine indiğimizde, standart web uygulamalarından çok daha farklı kısıtlamalar ve çözümlerle karşılaşıyoruz.
Protokol Seçimi: HTTP Yerine MQTT ve Binary İletişim
Her şey, o küçük IoT modülünün GSM ağı üzerinden kurduğu TCP soketiyle başlıyor. Burada HTTP/REST gibi metin tabanlı ve "header" yükü ağır protokollerin yeri yok. Bant genişliği ve enerji verimliliği kritik olduğu için, iletişim genellikle MQTT veya CoAP üzerinden, binary formatta ilerliyor. Özellikle MQTT’nin sunduğu QoS (Quality of Service) seviyeleri hayati önem taşıyor. Sürüşü bitirme komutu gibi finansal etkisi olan verilerde "QoS 2" (Exactly Once) ile verinin kaybolmadığından emin olurken, anlık telemetri verilerinde "QoS 0" (At most once) ile hızı tercih ediyoruz. Hatta veri boyutunu minimize etmek için JSON yerine Protocol Buffers (Protobuf) gibi serileştirme yöntemleri kullanarak payload’u sıkıştırmak, binlerce cihazlık bir filoda ciddi bir "network overhead" tasarrufu sağlıyor.
Kafka ve Veri Tabanı Ayrıştırma Stratejileri
Veri sunucuya ulaştığında ise bizi bambaşka bir dünya karşılıyor. Saniyede on binlerce "heartbeat" sinyalinin geldiği bir senaryoda, bu veriyi doğrudan PostgreSQL gibi ilişkisel bir veritabanına yazmaya çalışmak, I/O darboğazına davetiye çıkarmaktır. Bu yüzden mimarinin giriş kapısında Kafka gibi yüksek debili bir "Event Streaming" platformu konumlanıyor. Cihazdan gelen veri önce Kafka topic’lerine düşüyor, ardından consumer grupları tarafından işleniyor. Burada veriyi sınıflandırmak şart: Kullanıcı ve cüzdan bilgileri ilişkisel veritabanına giderken, cihazın saniyelik konum geçmişi ve voltaj değerleri gibi zaman damgalı veriler (Time-Series Data), TimescaleDB veya InfluxDB gibi bu iş için özelleşmiş sistemlere akıyor. Böylece analitik sorgularını koşarken ana operasyonel veritabanını yormamış oluyoruz.
Concurrency Yönetimi ve Distributed Locks
İşin en teknik ve heyecan verici tarafı ise "Concurrency" (Eşzamanlılık) yönetimi. Aynı scooter’ın QR kodunu iki farklı kullanıcı aynı saniyede okutursa ne olur? Bu klasik "Race Condition" problemini çözmek için veritabanı seviyesinde "Pessimistic Locking" kullanmak sistemi yavaşlatabilir. Bunun yerine Redis üzerinde dağıtık kilit mekanizmaları (Distributed Locks, örneğin Redlock algoritması) devreye giriyor. İlk isteği yapan kilit anahtarını (Key) kapıyor, diğer istek ise reddediliyor. Bu sayede veri bütünlüğü, milisaniyeler mertebesinde korunmuş oluyor.
Redis ile Yüksek Performanslı Coğrafi Sorgular
Son olarak, coğrafi hesaplamaların yükünü de veritabanından almak zorundayız. PostGIS güçlüdür evet, ama anlık akan veride her saniye "Point in Polygon" sorgusu yapmak maliyetlidir. Burada Redis’in Geospatial veri yapıları (GEOADD, GEOSEARCH) imdadımıza yetişiyor. Cihazın koordinatları bellek üzerinde tutulduğu için, yasaklı bölge kontrolü O(log(N)) karmaşıklığında, neredeyse sıfır gecikmeyle yapılabiliyor. Özetle; sokakta gördüğünüz o scooter, aslında gömülü sistemlerden bulut mimarisine, NoSQL veritabanlarından asenkron mesajlaşmaya kadar uzanan devasa bir teknoloji yığınının sadece görünen yüzü.