Qapu
Qapu, urun degil altyapi kararidir. Bu projenin varlik nedeni, farkli IoT urunleri icin ayri ayri backend kurup ayni sorunlari tekrar cozen bir ekip olmaktan cikmak ve tum sistemi tek bir teknik omurga etrafinda yonetmektir. Cinga, Maraba, WeatherStat ve ileride ayni ailenin parcasi olacak diger hatlar; veri alimi, kimlik, yetki, kural, komut, denetim ve entegrasyon gibi cekirdek davranislari her seferinde sifirdan tasarlamak yerine ayni platform disiplini uzerinden ilerlemelidir.
Bu nedenle Qapu, yalnizca yeni bir backend reposu degil; urun bazli daginikligin yerine platform bazli muhendislik koyma karari olarak ele alinmalidir. Buradaki hedef hizli olmak kadar tutarli olmak, esnek olmak kadar denetlenebilir kalmak ve urune ozel farklari buyuk teknik borca donusturmeden yonetebilmektir.
Qapu, farkli IoT urunleri icin ortak veri, kural, komut, yetki ve operasyon omurgasi kuran backend platformudur.
Neden dogdu?
Bu platformun cikis noktasi yalniz teknik tekrar degildir. Tekrar eden backend gelistirme maliyeti problemin gorunen yuzudur; asil sorun, her urunle birlikte veri modeli, kimlik mantigi, kural isletimi, komut akislari, izlenebilirlik ve entegrasyon disiplininin de dagilmasidir. Bu daginiklik kisa vadede hiz gibi gorunur, fakat orta vadede ekip her yeni urunde ayni mimari kararlari tekrar tekrar vermeye, ayni hatalari farkli yerlerde yeniden uretmeye ve kaliteyi kisiye bagli bir iyi niyet konusu olarak yonetmeye baslar.
Qapu, bu daginikligi platform duzeyinde bitirmeyi amaclar. Bir urunde dogru olan temel davranis; diger urunde tekrar tartisilan bir ihtimal degil, platformun varsayilan disiplini haline gelmelidir. Bu sayede ekip urune ozel deger uretecegi yerlere odaklanir; altyapisal kararlar ise her seferinde sifirdan kurulmaz.
Qapu ne degildir?
Qapu, yalnizca telemetriyi alip veritabanina yazan pasif bir depolama katmani degildir. Sadece cihazlardan veri toplayan basit bir ingest servisi de degildir. Ayri ayri urunlerin ihtiyacina gore gevsekce baglanmis utility servisler toplulugu hic degildir.
Daha da onemlisi, Qapu urunleri birbirine benzetmeye calisan bir dayatma mekanizmasi olarak tasarlanmamalidir. Platformun amaci urun farklarini yok etmek degil; bu farklarin cekirdek sistemi bozmasina izin vermeden yonetilebilir hale getirmektir. Farkliliklar adapter, konfigurasyon ve is kurali katmanlarinda yasanmali; veri ve operasyon omurgasi her urunle birlikte dagilmamalidir.
Proje amaci
Qapu'nun amaci yalnizca veri toplamak degildir; sahadan gelen telemetrinin guvenilir bicimde alinmasi, dogrulanmasi, kalibre edilmesi, sentezlenmesi, kurallarla degerlendirilmesi ve aksiyona donusmesi tek bir yasam dongusu olarak ele alinir. Ayni anda hem mobil uygulama hem admin operasyonlari hem de dis sistem entegrasyonlari ayni cekirdek ilkelere bagli kalir. Bu sayede hiz kazanirken kalite kaybetmeyen, buyudukce dagilmayan bir backend hatti kurulur.
Bu yasam dongusunun ozelligi, veriyi yalnizca saklamakla yetinmemesidir. Telemetri kabulunden rule evaluation'a, komut ve uzaktan yonetimden audit izlerine, mobil API'lerden dis sistem entegrasyonlarina kadar tum zincir ayni platform kararlarinin parcasi olarak ele alinir.
Temel ilkeler
Qapu'nun gucu tek bir teknolojiden degil, tekrar edilen birkaç basit ama tavizsiz ilkeden gelir. Ilk ilke, standart veri sozlesmesidir. Cihazlar standardize edilmis paketlerle iletim yapar, servisler ortak event envelope ile haberlesir ve tum zincir idempotent isleme, retry/backoff, DLQ ve izlenebilirlik kurallariyla calisir. Payload standardinin referansi /acik-kaynak/cps sayfasidir.
Ikinci ilke, urune ozel farklarin izole edilmesidir. Cekirdek servis davranisi urune gore degismez; farklar adapter, konfigurasyon ve is kurali katmanlarinda tanimlanir. Ucuncu ilke ise denetlenebilirliktir. Audit izi, kim ne yapti sorusunu sonradan cevaplamak icin degil; sistem tasarlanirken zorunlu kabul edilmesi gereken bir omurgadir.
Qapu'nun her yeni urune sordugu soru su olmalidir: bu fark cekirdek sistemi mi degistiriyor, yoksa adapter ve kural katmaninda mi izole edilebilir?
Mimari yaklasim
Qapu, mikroservis tabanli event-driven bir mimariyi temel alir. Kafka olay akislarini tasir, Redis gecici state ve kuyruk basincini yonetir, PostgreSQL iliskisel dogruluk ve operasyonel sureklilik icin ana kayit sistemi olur. Servis sinirlari veri alimi ve isleme hattindan karar ve aksiyon katmanina, oradan da entegrasyon ve gozlemlenebilirlik katmanina uzanan net bir ayrimla tanimlanir.
Bu ayrim yalniz akademik bir servis siniri tercihi degildir. Amaç, veri alimi ile is kurali calistirma sorumlulugunu, komut gonderimi ile denetim izini, mobil API ile cihaz kabul katmanini birbirine dolayarak kisa vadeli hiz kazanmaya calismamak; bunun yerine buyudukce bozulmayacak operasyonel bir omurga kurmaktir.
Kapsam
Qapu, telemetriyi alip saklayan pasif bir katman degil, uctan uca operasyon platformudur. IoT veri alimi ve isleme, kural motoru, cihaz komut ve uzaktan yonetim, firmware dagitimi, mobil ve admin API katmanlari ile dis sistemlere kontrollu veri cikisi ayni kapsamda yonetilir. Bu kapsam, ekibin bugun kurdugu yapinin yarin farkli urunler tarafindan da dogrudan kullanilabilmesini hedefler.
Buradaki hedef "tek backend" sahibi olmak degil; bir urunde gelistirilen teknik disiplinin baska urunlerde sifirdan yeniden kurulmasini gereksiz hale getirmektir.
Urunlerle iliskisi
Qapu'nun en kritik tasarim karari, urunlerle rekabet etmeyen ama onlari tasiyan katman olmasidir. Cinga enerji ve altyapi odaklidir. Maraba tarim ve sulama operasyonuna yakindir. WeatherStat mikro iklim ve saha gozetimi baglaminda farkli ihtiyaclar tasir. Bunlarin her biri farkli urunlerdir; ancak hepsi veri kabul, kimlik, denetim, rule, komut, entegrasyon ve operasyon omurgasinda ayni temel disiplinden beslenir.
Bu nedenle Qapu, urunleri tek tip hale getiren bir kalip degil; urunlerin farkli kimliklerini koruyarak ayni muhendislik omurgasi uzerinde yasamasini saglayan platformdur.
Onceliklendirme
Ilk faz odaimiz enerji ve tarim odakli urunlerdir. Bu alanlarda platform davranisi olgunlastikca endustriyel uygulamalar ikinci fazda ayni omurga uzerinde konumlandirilacaktir. Yol haritasi urun cesitliligiyle degil, platform olgunluguyla ilerler.
Bu tercih bilinclidir. Qapu once her seye hitap eden soyut bir platform olmak yerine, gercek urun baskisi altinda dogru davranan omurgaya donusmelidir. Enerji ve tarim tarafi bu olgunlasma icin yeterince zengin ve yeterince zorludur.
Temel kabiliyetler
Qapu'nun cekirdek kabiliyetleri coklu proje destegi, ortak rule engine, ortak command registry ve uygulamalar arasi tek kimlik omurgasi etrafinda toplanir. Buna gozlemlenebilirlik, audit izleri, dusuk baglanti kosullarinda calisma dayanimi, tak-calistir yeni proje acma disiplini ve uzaktan cihaz-firmware yonetimi eklendiginde platform hem teknik olarak olceklenebilir hem de operasyonel olarak denetlenebilir hale gelir.
Bu kabiliyetler yalniz bugunku urunleri desteklemek icin degil, gelecekte eklenecek her yeni hatta ayni disiplinin sifirdan anlatilmasini gereksiz kılmak icin vardir.
Bu dokuman nasil okunmali?
Bu giris sayfasi, Qapu'nun neden var oldugunu ve hangi ilkelere dayandigini anlatan ust seviye teknik karar kaydidir. Detayli servis ve akis aciklamalari Mimari sayfasinda, veritabani ve tablo iliskileri ise Veri Modeli bolumunde tutulur. Bu iki dokuman birlikte okundugunda Qapu'nun yalnizca ne oldugu degil, nasil isletilecegi de netlesir.