G\u00fcn\u00fcm\u00fcz\u00fcn h\u0131zla de\u011fi\u015fen dijital d\u00fcnyas\u0131nda, yaz\u0131l\u0131m sistemlerinin \u00f6l\u00e7eklenebilir, performansl\u0131 ve g\u00fcvenilir olmas\u0131 kritik bir \u00f6neme sahiptir. Peki, bir sistemin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 azalt\u0131rken ayn\u0131 zamanda bu hedeflere ula\u015fmak m\u00fcmk\u00fcn m\u00fcd\u00fcr? Model Ba\u011flam Protokol\u00fc’n\u00fcn (MCP) durumsuz mimariyi benimsemesi, bu soruya g\u00fc\u00e7l\u00fc bir “evet” yan\u0131t\u0131 vererek modern uygulama geli\u015ftirmede yeni bir d\u00f6nemi ba\u015flat\u0131yor.<\/p>\n
Yaz\u0131l\u0131m mimarilerini anlamak i\u00e7in \u00f6ncelikle “durum” kavram\u0131n\u0131 iyi kavramak gerekir. Bir sistemin durumu, belirli bir anda sahip oldu\u011fu veriler ve bu verilerin konfig\u00fcrasyonudur. Bu durumun nerede ve nas\u0131l y\u00f6netildi\u011fi, mimarinin temel karakteristi\u011fini belirler. Geleneksel olarak, iki ana yakla\u015f\u0131m bulunmaktad\u0131r: durum bilgili (stateful) ve durumsuz (stateless) mimariler.<\/p>\n
Durum bilgili (stateful) mimarilerde, sunucu her istemci iste\u011fi aras\u0131nda belirli bir ba\u011flam\u0131 veya “durumu” saklar. Bu durum, genellikle bir oturum (session) kimli\u011fi arac\u0131l\u0131\u011f\u0131yla takip edilir ve sunucunun belle\u011finde veya kal\u0131c\u0131 depolamas\u0131nda tutulur. \u00d6rne\u011fin, bir al\u0131\u015fveri\u015f sitesindeki sepet uygulamas\u0131, kullan\u0131c\u0131n\u0131n sepete ekledi\u011fi \u00fcr\u00fcnleri sunucu taraf\u0131nda bir oturum de\u011fi\u015fkeninde tutuyorsa, bu durum bilgili bir yakla\u015f\u0131md\u0131r. Her istek geldi\u011finde, sunucu \u00f6nce oturum kimli\u011fini kontrol eder, ilgili durumu y\u00fckler ve ard\u0131ndan iste\u011fi i\u015fler. Bu yakla\u015f\u0131m, basit uygulamalar i\u00e7in kolay bir ba\u015flang\u0131\u00e7 sunsa da, beraberinde ciddi zorluklar getirir. Sunucunun \u00e7\u00f6kmesi durumunda oturum bilgileri kaybolabilir, yatay \u00f6l\u00e7eklendirme (horizontal scaling) zorla\u015f\u0131r \u00e7\u00fcnk\u00fc her sunucunun ayn\u0131 oturum bilgilerine eri\u015fmesi veya oturumlar\u0131n sunucular aras\u0131nda payla\u015f\u0131lmas\u0131 gerekir ki bu da karma\u015f\u0131k bir yap\u0131d\u0131r. Ayr\u0131ca, sunucu \u00fczerinde tutulan durum, kaynak t\u00fcketimini art\u0131r\u0131r ve sunucunun genel performans\u0131n\u0131 olumsuz etkileyebilir.<\/p>\n
Di\u011fer yandan, durumsuz (stateless) mimarilerde, sunucu hi\u00e7bir istemci iste\u011fi aras\u0131nda herhangi bir ba\u011flam veya durum saklamaz. Her istek tamamen ba\u011f\u0131ms\u0131zd\u0131r ve iste\u011fi i\u015flemek i\u00e7in gerekli t\u00fcm bilgiler (kimlik do\u011frulama, yetkilendirme, i\u015flem ba\u011flam\u0131 vb.) do\u011frudan iste\u011fin kendisiyle birlikte g\u00f6nderilir. Sunucu, bir iste\u011fi i\u015fledikten sonra, o istekle ilgili hi\u00e7bir bilgiyi saklamaz. Yukar\u0131daki al\u0131\u015fveri\u015f sepeti \u00f6rne\u011fini ele al\u0131rsak, durumsuz bir mimaride, sepet i\u00e7eri\u011fi sunucuda tutulmaz; bunun yerine, her istekte sepet bilgisi istemciden (\u00f6rne\u011fin, bir \u00e7erezde, yerel depolamada veya istek g\u00f6vdesinde) g\u00f6nderilir. Sunucu bu bilgiyi kullanarak i\u015flemi tamamlar ve sonu\u00e7lar\u0131 geri d\u00f6ner. Bu yakla\u015f\u0131m\u0131n en b\u00fcy\u00fck avantajlar\u0131ndan biri, sistemin kolayca yatay olarak \u00f6l\u00e7eklenebilmesidir. Herhangi bir sunucu, herhangi bir iste\u011fi i\u015fleyebilir \u00e7\u00fcnk\u00fc her iste\u011fin kendi i\u00e7inde t\u00fcm gerekli bilgileri bar\u0131nd\u0131r\u0131r. Bu durum, y\u00fck dengeleyicilerin (load balancer) i\u015fini kolayla\u015ft\u0131r\u0131r ve sunucu ar\u0131zalar\u0131na kar\u015f\u0131 daha y\u00fcksek hata tolerans\u0131 sa\u011flar. Ayr\u0131ca, sunucu taraf\u0131nda durum y\u00f6netimi y\u00fck\u00fc ortadan kalkt\u0131\u011f\u0131 i\u00e7in performans art\u0131\u015f\u0131 g\u00f6zlemlenir ve kaynak t\u00fcketimi azal\u0131r. Ancak, bu durum, istemcinin daha fazla sorumluluk almas\u0131n\u0131 ve ba\u011flam y\u00f6netimini do\u011fru bir \u015fekilde yapmas\u0131n\u0131 gerektirir.<\/p>\n
Bu iki mimari aras\u0131ndaki tercih, uygulaman\u0131n gereksinimlerine, \u00f6l\u00e7eklenebilirlik hedeflerine ve geli\u015ftirme ekibinin tecr\u00fcbesine ba\u011fl\u0131d\u0131r. Ancak modern bulut tabanl\u0131, mikroservis odakl\u0131 ve da\u011f\u0131t\u0131k sistemlerde durumsuz mimarinin sundu\u011fu avantajlar, onu giderek daha cazip hale getirmektedir. Model Ba\u011flam Protokol\u00fc (MCP) de bu modern yakla\u015f\u0131mlar\u0131 benimseyerek, durumsuz mimarinin g\u00fcc\u00fcnden faydalanmay\u0131 hedeflemektedir.<\/p>\n
Model Ba\u011flam Protokol\u00fc (MCP), \u00f6zellikle karma\u015f\u0131k ve da\u011f\u0131t\u0131k sistemlerde ba\u011flam y\u00f6netimini standartla\u015ft\u0131rmak ve basitle\u015ftirmek amac\u0131yla geli\u015ftirilmi\u015f yenilik\u00e7i bir yakla\u015f\u0131md\u0131r. Geleneksel uygulama geli\u015ftirme s\u00fcre\u00e7lerinde, farkl\u0131 servisler veya mod\u00fcller aras\u0131nda bilgi ak\u0131\u015f\u0131n\u0131 ve ortak bir ba\u011flam\u0131 s\u00fcrd\u00fcrmek genellikle b\u00fcy\u00fck bir zorluk te\u015fkil eder. \u00d6zellikle mikroservis mimarileri gibi ba\u011f\u0131ms\u0131z servislerin bir araya gelerek b\u00fcy\u00fck bir sistemi olu\u015fturdu\u011fu senaryolarda, bir kullan\u0131c\u0131n\u0131n veya i\u015flemin mevcut durumunu (\u00f6rne\u011fin, kimlik bilgileri, yetkileri, tercihleri veya devam eden bir i\u015flemin a\u015famas\u0131) her servise tutarl\u0131 bir \u015fekilde iletmek ve y\u00f6netmek olduk\u00e7a karma\u015f\u0131k hale gelebilir.<\/p>\n
Bu karma\u015f\u0131kl\u0131k, genellikle “ba\u011flam yay\u0131l\u0131m\u0131” (context propagation) olarak bilinen bir sorunu do\u011furur. Her servis, kendi ihtiyac\u0131na g\u00f6re ba\u011flam bilgilerini i\u015fler ve bir sonraki servise aktar\u0131r. Bu durum, manuel kodlama hatalar\u0131na, tutars\u0131z verilere ve sistem genelinde hata ay\u0131klama (debugging) s\u00fcre\u00e7lerinin zorla\u015fmas\u0131na yol a\u00e7ar. Ayr\u0131ca, ba\u011flam\u0131n sunucu taraf\u0131nda oturumlar veya kal\u0131c\u0131 depolama yoluyla y\u00f6netilmesi, yukar\u0131da bahsedildi\u011fi gibi \u00f6l\u00e7eklenebilirlik ve performans darbo\u011fazlar\u0131 yarat\u0131r. MCP, bu sorunlar\u0131 \u00e7\u00f6zmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Temel amac\u0131, sistemin farkl\u0131 katmanlar\u0131 ve servisleri aras\u0131nda ba\u011flam bilgisinin g\u00fcvenli, verimli ve standart bir \u015fekilde ta\u015f\u0131nmas\u0131n\u0131 sa\u011flamakt\u0131r.<\/p>\n
MCP, \u00f6zellikle mikroservis, bulut tabanl\u0131 ve sunucusuz (serverless) mimarilerin yayg\u0131nla\u015fmas\u0131yla birlikte daha da \u00f6nem kazanm\u0131\u015ft\u0131r. Bu modern mimarilerde, servisler aras\u0131ndaki etkile\u015fimlerin say\u0131s\u0131 ve karma\u015f\u0131kl\u0131\u011f\u0131 artarken, her bir servisin ba\u011f\u0131ms\u0131z ve \u00f6l\u00e7eklenebilir kalabilmesi i\u00e7in durumsuz ba\u011flam y\u00f6netimi vazge\u00e7ilmez bir hale gelmi\u015ftir. MCP, bu ihtiyaca yan\u0131t vererek geli\u015ftiricilere daha tutarl\u0131, y\u00f6netilebilir ve \u00f6l\u00e7eklenebilir sistemler in\u015fa etme olana\u011f\u0131 sunar. Protokol\u00fcn benimsenmesi, hem geli\u015ftirme s\u00fcre\u00e7lerini h\u0131zland\u0131r\u0131r hem de son kullan\u0131c\u0131ya daha g\u00fcvenilir ve h\u0131zl\u0131 uygulamalar sunar.<\/p>\n
Model Ba\u011flam Protokol\u00fc’n\u00fcn (MCP) en temel ve ay\u0131rt edici \u00f6zelliklerinden biri, durumsuz (stateless) mimari prensiplerini benimsemesidir. Bu entegrasyon, ba\u011flam y\u00f6netimini sunucu taraf\u0131ndaki oturum ba\u011f\u0131ml\u0131l\u0131klar\u0131ndan kurtararak, sistemin genel \u00f6l\u00e7eklenebilirli\u011fini, performans\u0131n\u0131 ve hata tolerans\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Peki, bu durumsuzluk MCP’ye nas\u0131l entegre ediliyor ve pratik uygulamalar\u0131 nelerdir?<\/p>\n
Durumsuz bir MCP uygulamas\u0131nda, sunucu bir istemcinin durumunu (ba\u011flam\u0131n\u0131) kendi belle\u011finde veya veritaban\u0131nda saklamak yerine, bu ba\u011flam\u0131 do\u011frudan istemciye geri g\u00f6nderir. \u0130stemci, bir sonraki iste\u011finde bu ba\u011flam\u0131 tekrar sunucuya iletir. Bu, genellikle a\u015fa\u011f\u0131daki mekanizmalar arac\u0131l\u0131\u011f\u0131yla ger\u00e7ekle\u015ftirilir:<\/p>\n
Authorization: Bearer [token]<\/code> format\u0131nda) sunucuya geri g\u00f6nderir. Sunucu, token’\u0131 imzas\u0131n\u0131 do\u011frulayarak ve i\u00e7eri\u011fini \u00e7\u00f6zerek kullan\u0131c\u0131n\u0131n ba\u011flam\u0131na eri\u015fir. Bu sayede sunucu, herhangi bir oturum bilgisi tutmak zorunda kalmaz.\n <\/li>\n- \n HTTP Ba\u015fl\u0131klar\u0131:<\/strong> JWT’lerin yan\u0131 s\u0131ra, di\u011fer ba\u011flam bilgileri de \u00f6zel HTTP ba\u015fl\u0131klar\u0131 arac\u0131l\u0131\u011f\u0131yla ta\u015f\u0131nabilir. \u00d6rne\u011fin, bir i\u015flem kimli\u011fi (
X-Transaction-ID<\/code>), bir kullan\u0131c\u0131n\u0131n tercih etti\u011fi dil (Accept-Language<\/code>) veya bir A\/B testi grubu (X-AB-Test-Group<\/code>) gibi bilgiler, her istekte ba\u015fl\u0131klar arac\u0131l\u0131\u011f\u0131yla iletilebilir. MCP, bu ba\u015fl\u0131klar\u0131n standart bir formatta olmas\u0131n\u0131 sa\u011flayarak farkl\u0131 servisler aras\u0131nda tutarl\u0131 bir ba\u011flam yay\u0131l\u0131m\u0131 sunar.<\/li>\n- \n \u0130stek G\u00f6vdesi (Request Body):<\/strong> \u00d6zellikle POST veya PUT isteklerinde, ba\u011flam bilgileri iste\u011fin JSON veya XML g\u00f6vdesine de dahil edilebilir. Bu y\u00f6ntem, daha b\u00fcy\u00fck ve karma\u015f\u0131k ba\u011flam verileri i\u00e7in uygun olabilir, ancak genellikle ba\u015fl\u0131klar kadar yayg\u0131n de\u011fildir.\n <\/li>\n<\/ul>\n
Sunucu Taraf\u0131nda Durum Tutmama \u0130lkesi<\/h3>\n
Durumsuzlu\u011fun temel ilkesi, her sunucunun her iste\u011fi ba\u011f\u0131ms\u0131z olarak i\u015fleyebilmesidir. Bu, sunucunun \u00f6nceki istekler hakk\u0131nda hi\u00e7bir haf\u0131zaya sahip olmamas\u0131 gerekti\u011fi anlam\u0131na gelir. Bir istek geldi\u011finde, sunucu gerekli t\u00fcm bilgileri (JWT, ba\u015fl\u0131klar vb.) do\u011frudan istekten al\u0131r, i\u015flemi tamamlar ve bir yan\u0131t d\u00f6nd\u00fcr\u00fcr. Bu model, \u00f6zellikle yatay \u00f6l\u00e7eklendirme i\u00e7in hayati \u00f6neme sahiptir. Yeni sunucular sisteme eklendi\u011finde, herhangi bir \u00f6zel konfig\u00fcrasyona veya oturum senkronizasyonuna ihtiya\u00e7 duymadan hemen istekleri i\u015flemeye ba\u015flayabilirler. Bu durum, hata tolerans\u0131n\u0131 da art\u0131r\u0131r; bir sunucu \u00e7\u00f6kerse, y\u00fck dengeleyici istekleri otomatik olarak ba\u015fka bir sunucuya y\u00f6nlendirebilir ve kullan\u0131c\u0131, durum kayb\u0131 ya\u015famadan i\u015flemini s\u00fcrd\u00fcrebilir.<\/p>\n
\u00d6rnek Senaryo: Bir API \u0130ste\u011finin Ya\u015fam D\u00f6ng\u00fcs\u00fc<\/h3>\n
Bir e-ticaret uygulamas\u0131nda \u00fcr\u00fcn listeleme API’sini d\u00fc\u015f\u00fcnelim:<\/p>\n
\n- Kullan\u0131c\u0131, mobil uygulamas\u0131ndan \u00fcr\u00fcn listesini ister.<\/li>\n
- Uygulama, kullan\u0131c\u0131n\u0131n daha \u00f6nce ald\u0131\u011f\u0131 JWT’yi
Authorization<\/code> ba\u015fl\u0131\u011f\u0131na ekler ve sunucuya bir HTTP GET iste\u011fi g\u00f6nderir. Ayr\u0131ca, kullan\u0131c\u0131n\u0131n tercih etti\u011fi kategori veya filtreleme bilgileri gibi ba\u011flam verilerini de iste\u011fin URL parametrelerine veya \u00f6zel HTTP ba\u015fl\u0131klar\u0131na ekleyebilir.<\/li>\n- Y\u00fck dengeleyici (load balancer), iste\u011fi mevcut ve az y\u00fckl\u00fc bir API sunucusuna y\u00f6nlendirir.<\/li>\n
- API sunucusu, iste\u011fi al\u0131r. \u00d6ncelikle JWT’yi do\u011frular (imzas\u0131n\u0131 kontrol eder ve s\u00fcresinin ge\u00e7ip ge\u00e7medi\u011fini kontrol eder). E\u011fer token ge\u00e7erliyse, i\u00e7indeki kullan\u0131c\u0131 kimli\u011fini ve yetkilerini \u00e7\u0131kar\u0131r.<\/li>\n
- Sunucu, iste\u011fin URL parametreleri ve ba\u015fl\u0131klar\u0131ndaki filtreleme bilgilerini kullanarak veritaban\u0131ndan \u00fcr\u00fcnleri \u00e7eker.<\/li>\n
- \u00dcr\u00fcn listesi, bir JSON yan\u0131t\u0131 olarak istemciye geri g\u00f6nderilir.<\/li>\n
- API sunucusu, bu istekle ilgili hi\u00e7bir bilgiyi saklamaz. Bir sonraki istek geldi\u011finde, ayn\u0131 s\u00fcre\u00e7 ba\u015ftan ba\u015flar.<\/li>\n<\/ol>\n
Bu senaryoda, sunucu hi\u00e7bir zaman kullan\u0131c\u0131n\u0131n oturumunu veya ba\u011flam\u0131n\u0131 kendi \u00fczerinde tutmad\u0131. T\u00fcm gerekli bilgiler, her istekle birlikte geldi. Bu, MCP’nin durumsuz mimariyi nas\u0131l etkin bir \u015fekilde kulland\u0131\u011f\u0131n\u0131n bir \u00f6rne\u011fidir.<\/p>\n
Kod \u00d6rne\u011fi: Basit Bir HTTP \u0130ste\u011fi ve Ba\u015fl\u0131kta Ba\u011flam Ta\u015f\u0131ma<\/h3>\n
A\u015fa\u011f\u0131daki JavaScript (Node.js) kod blo\u011fu, bir istemcinin bir JWT’yi ve \u00f6zel bir ba\u011flam ba\u015fl\u0131\u011f\u0131n\u0131 nas\u0131l g\u00f6nderebilece\u011fini g\u00f6sterir:<\/p>\n
\n\nconst axios = require('axios');\n\nasync function getProductsWithContext() {\n const userToken = \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjMiLCJyb2xlIjoiY3VzdG9tZXIiLCJpYXQiOjE2NzgyNjI0MDB9.EXAMPLE_JWT_SIGNATURE\"; \/\/ \u00d6rnek bir JWT\n const preferredCategory = \"elektronik\";\n\n try {\n const response = await axios.get('https:\/\/api.example.com\/products', {\n headers: {\n 'Authorization': Bearer ${userToken}<\/code>,\n 'X-Preferred-Category': preferredCategory,\n 'Content-Type': 'application\/json'\n },\n params: {\n limit: 10,\n offset: 0\n }\n });\n console.log(\"\u00dcr\u00fcnler ba\u015far\u0131yla \u00e7ekildi:\", response.data);\n } catch (error) {\n console.error(\"\u00dcr\u00fcnler \u00e7ekilirken hata olu\u015ftu:\", error.message);\n }\n}\n\ngetProductsWithContext();\n <\/code><\/pre>\n<\/p><\/div>\nBu \u00f6rnekte, userToken<\/code> ve preferredCategory<\/code> bilgileri, sunucunun herhangi bir durum bilgisi tutmas\u0131na gerek kalmadan, her istekte istemci taraf\u0131ndan sa\u011flanmaktad\u0131r. Sunucu taraf\u0131nda ise bu ba\u015fl\u0131klar okunarak ilgili i\u015flemler yap\u0131l\u0131r. Bu yap\u0131, MCP’nin durumsuz entegrasyonunun temelini olu\u015fturur ve modern da\u011f\u0131t\u0131k sistemlerin vazge\u00e7ilmez bir par\u00e7as\u0131 haline gelmi\u015ftir.<\/p>\nDurumsuz MCP’nin Getirdi\u011fi Avantajlar Nelerdir?<\/h2>\n
Model Ba\u011flam Protokol\u00fc’n\u00fcn (MCP) durumsuz mimariyi benimsemesi, modern yaz\u0131l\u0131m geli\u015ftirme pratiklerinde devrim niteli\u011finde avantajlar sunar. Bu avantajlar, sadece teknik karma\u015f\u0131kl\u0131\u011f\u0131 azaltmakla kalmaz, ayn\u0131 zamanda i\u015f s\u00fcre\u00e7lerine de do\u011frudan katk\u0131da bulunur. Gelin, bu \u00f6nemli faydalar\u0131 ve ger\u00e7ek d\u00fcnya senaryolar\u0131ndaki yans\u0131malar\u0131n\u0131 detayl\u0131ca inceleyelim.<\/p>\n
1. Ola\u011fan\u00fcst\u00fc \u00d6l\u00e7eklenebilirlik (Scalability)<\/h3>\n
Durumsuz mimarinin en b\u00fcy\u00fck faydas\u0131, sistemlerin yatay olarak (horizontal scaling) kolayca \u00f6l\u00e7eklenebilmesidir. Her istek kendi i\u00e7inde t\u00fcm gerekli ba\u011flam\u0131 ta\u015f\u0131d\u0131\u011f\u0131 i\u00e7in, herhangi bir sunucu herhangi bir iste\u011fi i\u015fleyebilir. Bu, y\u00fck dengeleyicilerin (load balancer) gelen istekleri mevcut sunucular aras\u0131nda e\u015fit bir \u015fekilde da\u011f\u0131tmas\u0131n\u0131 son derece basitle\u015ftirir. Yeni bir sunucu eklemek veya mevcut bir sunucuyu \u00e7\u0131karmak, oturum senkronizasyonu veya durum transferi gibi karma\u015f\u0131k i\u015flemler gerektirmez. Uygulama, talep artt\u0131\u011f\u0131nda dinamik olarak daha fazla sunucu ekleyebilir ve talep azald\u0131\u011f\u0131nda sunucular\u0131 kald\u0131rarak maliyetleri optimize edebilir. Bu esneklik, \u00f6zellikle bulut ortamlar\u0131nda ve de\u011fi\u015fken kullan\u0131c\u0131 trafi\u011fi olan uygulamalar i\u00e7in hayati \u00f6neme sahiptir. \u00d6rne\u011fin, Black Friday gibi yo\u011fun al\u0131\u015fveri\u015f d\u00f6nemlerinde anl\u0131k olarak y\u00fcz binlerce e\u015f zamanl\u0131 iste\u011fi kar\u015f\u0131lamas\u0131 gereken bir e-ticaret platformu, durumsuz bir mimari sayesinde kolayca \u00f6l\u00e7eklenerek kesintisiz hizmet verebilir.<\/p>\n
2. Geli\u015fmi\u015f Performans<\/h3>\n
Sunucular\u0131n her istek aras\u0131nda durum bilgisi tutma zorunlulu\u011funun ortadan kalkmas\u0131, \u00f6nemli performans art\u0131\u015flar\u0131 sa\u011flar. Durum bilgili sistemlerde, sunucunun her istekte oturum verilerini belle\u011fe y\u00fcklemesi, g\u00fcncellemesi ve bazen de kal\u0131c\u0131 depolamaya yazmas\u0131 gerekir. Bu i\u015flemler, CPU ve I\/O kaynaklar\u0131n\u0131 t\u00fcketir. Durumsuz bir MCP’de ise sunucu sadece iste\u011fi i\u015fler ve yan\u0131t\u0131 d\u00f6nd\u00fcr\u00fcr. Bu durum, sunucu y\u00fck\u00fcn\u00fc azalt\u0131r, gecikme s\u00fcresini (latency) d\u00fc\u015f\u00fcr\u00fcr ve ayn\u0131 donan\u0131m kaynaklar\u0131yla daha fazla iste\u011fi i\u015fleyebilme kapasitesi sunar. \u00d6zellikle d\u00fc\u015f\u00fck gecikme s\u00fcresinin kritik oldu\u011fu finansal uygulamalar veya ger\u00e7ek zamanl\u0131 veri i\u015fleme sistemleri i\u00e7in bu performans art\u0131\u015f\u0131 b\u00fcy\u00fck fark yarat\u0131r.<\/p>\n
3. Y\u00fcksek Hata Tolerans\u0131 (Fault Tolerance)<\/h3>\n
Durumsuz mimariler, sunucu ar\u0131zalar\u0131na kar\u015f\u0131 do\u011fal bir diren\u00e7 g\u00f6sterir. Bir sunucu aniden \u00e7\u00f6kerse, y\u00fck dengeleyici otomatik olarak istekleri di\u011fer \u00e7al\u0131\u015fan sunuculara y\u00f6nlendirebilir. Kullan\u0131c\u0131, durum bilgisi sunucu taraf\u0131nda tutulmad\u0131\u011f\u0131 i\u00e7in, i\u015flemini kesintiye u\u011framadan devam ettirebilir. Hi\u00e7bir oturum verisi kaybolmaz \u00e7\u00fcnk\u00fc t\u00fcm ba\u011flam istemci taraf\u0131ndan yeniden g\u00f6nderilir. Bu \u00f6zellik, sistemin genel g\u00fcvenilirli\u011fini art\u0131r\u0131r ve kesintisiz hizmet sunma yetene\u011fini g\u00fc\u00e7lendirir. Hastane bilgi y\u00f6netim sistemleri veya acil durum hizmetleri gibi kritik altyap\u0131larda, sistemin her zaman eri\u015filebilir olmas\u0131 gerekti\u011fi durumlarda durumsuzluk, felaket kurtarma senaryolar\u0131nda b\u00fcy\u00fck bir avantaj sa\u011flar.<\/p>\n
4. Basitlik ve Geli\u015ftirme Kolayl\u0131\u011f\u0131<\/h3>\n
Sunucu taraf\u0131nda durum y\u00f6netimi karma\u015f\u0131kl\u0131\u011f\u0131n\u0131n azalmas\u0131, geli\u015ftirme s\u00fcre\u00e7lerini basitle\u015ftirir. Geli\u015ftiriciler, oturumlar\u0131 nas\u0131l y\u00f6netecekleri, oturum replikasyonunu nas\u0131l sa\u011flayacaklar\u0131 veya kal\u0131c\u0131 depolama ile nas\u0131l entegre olacaklar\u0131 gibi konularla u\u011fra\u015fmak zorunda kalmazlar. Her servis, kendi i\u00e7inde ba\u011f\u0131ms\u0131z bir birim olarak d\u00fc\u015f\u00fcn\u00fclebilir ve bu da mikroservis mimarilerinin temel felsefesiyle m\u00fckemmel bir uyum i\u00e7indedir. Bu basitlik, kod taban\u0131n\u0131n daha temiz, daha anla\u015f\u0131l\u0131r olmas\u0131n\u0131 sa\u011flar ve yeni \u00f6zelliklerin daha h\u0131zl\u0131 geli\u015ftirilmesine olanak tan\u0131r. Yeni geli\u015ftiricilerin projeye adaptasyon s\u00fcresi de k\u0131sal\u0131r.<\/p>\n
5. Geli\u015ftirilmi\u015f G\u00fcvenlik (Potansiyel)<\/h3>\n
Durumun sunucuda saklanmamas\u0131, baz\u0131 g\u00fcvenlik faydalar\u0131 da sunabilir. \u00d6rne\u011fin, sunucu taraf\u0131nda hassas oturum verilerinin tutulmamas\u0131, oturum ele ge\u00e7irme (session hijacking) gibi sald\u0131r\u0131lar\u0131n etkisini azaltabilir. E\u011fer bir sald\u0131rgan bir sunucuya eri\u015fim sa\u011flasa bile, o sunucuda kal\u0131c\u0131 olarak saklanan aktif oturum bilgileri bulma olas\u0131l\u0131\u011f\u0131 d\u00fc\u015f\u00fckt\u00fcr. Ancak, bu durumun istemci taraf\u0131nda ta\u015f\u0131nan token’lar\u0131n (\u00f6rn. JWT) do\u011fru bir \u015fekilde imzalanmas\u0131, \u015fifrelenmesi ve k\u0131sa \u00f6m\u00fcrl\u00fc olmas\u0131 gibi ek g\u00fcvenlik \u00f6nlemleriyle desteklenmesi gerekti\u011fini unutmamak \u00f6nemlidir. G\u00fcvenli token y\u00f6netimi, durumsuz mimaride kritik bir g\u00fcvenlik bile\u015fenidir.<\/p>\n
Vaka Analizi: B\u00fcy\u00fck Bir E-ticaret Platformunun Durumsuz Mimariye Ge\u00e7i\u015fi<\/h3>\n
T\u00fcrkiye’nin \u00f6nde gelen bir e-ticaret platformu, ilk y\u0131llar\u0131nda durum bilgili bir mimari kullan\u0131yordu. Kullan\u0131c\u0131 sepetleri, oturum bilgileri ve ki\u015fiselle\u015ftirilmi\u015f \u00f6neriler sunucu taraf\u0131ndaki oturum veritabanlar\u0131nda saklan\u0131yordu. Ancak, \u00f6zellikle \u00f6zel g\u00fcnlerdeki (Kara Cuma, Anneler G\u00fcn\u00fc vb.) ani trafik art\u0131\u015flar\u0131nda sistem ciddi performans sorunlar\u0131 ya\u015famaya ba\u015flad\u0131. Y\u00fck dengeleyiciler, oturumlar\u0131n hangi sunucuda oldu\u011funu bilmek zorunda oldu\u011fu i\u00e7in karma\u015f\u0131kla\u015f\u0131yor, oturum replikasyonu ise sunucular aras\u0131nda ciddi a\u011f trafi\u011fi yarat\u0131yordu. Yeni sunucular eklemek bile oturum senkronizasyonu nedeniyle sisteme entegrasyon s\u00fcresini uzat\u0131yordu.<\/p>\n
Platform, bu sorunlar\u0131 \u00e7\u00f6zmek i\u00e7in durumsuz bir mikroservis mimarisine ge\u00e7i\u015f karar\u0131 ald\u0131. Kullan\u0131c\u0131 kimlik do\u011frulama i\u00e7in JWT’ler kullan\u0131ld\u0131. Sepet bilgileri, art\u0131k sunucu taraf\u0131nda oturumda tutulmak yerine, istemcinin yerel depolamas\u0131nda (localStorage) veya \u00e7erezlerde \u015fifrelenmi\u015f bir \u015fekilde sakland\u0131 ve her istekte API’ye g\u00f6nderildi. Ki\u015fiselle\u015ftirme verileri ise, kullan\u0131c\u0131n\u0131n JWT’sindeki kimlik bilgisiyle bir “\u00f6neri servisi” taraf\u0131ndan anl\u0131k olarak \u00e7ekildi. Bu ge\u00e7i\u015fin sonu\u00e7lar\u0131 \u00e7arp\u0131c\u0131yd\u0131:<\/p>\n
\n- \u00d6l\u00e7eklenebilirlik:<\/strong> Trafik art\u0131\u015flar\u0131nda sunucu eklemek saniyeler i\u00e7inde ger\u00e7ekle\u015febildi. Sistem, %99.99’un \u00fczerinde bir \u00e7al\u0131\u015fma s\u00fcresi (uptime) ile rekor seviyede e\u015f zamanl\u0131 kullan\u0131c\u0131ya hizmet verdi.<\/li>\n
- Performans:<\/strong> API yan\u0131t s\u00fcreleri ortalama %30 oran\u0131nda azald\u0131. Sunucu ba\u015f\u0131na d\u00fc\u015fen istek i\u015fleme kapasitesi \u00f6nemli \u00f6l\u00e7\u00fcde artt\u0131.<\/li>\n
- Geli\u015ftirme H\u0131z\u0131:<\/strong> Her mikroservisin ba\u011f\u0131ms\u0131z olmas\u0131 ve durum y\u00f6netimiyle u\u011fra\u015fmamas\u0131 sayesinde, yeni \u00f6zelliklerin geli\u015ftirilme ve devreye al\u0131nma s\u00fcresi k\u0131sald\u0131.<\/li>\n<\/ul>\n
Bu vaka analizi, durumsuz MCP’nin sadece teorik bir kavram olmad\u0131\u011f\u0131n\u0131, ayn\u0131 zamanda ger\u00e7ek d\u00fcnya problemlerine somut ve \u00f6l\u00e7\u00fclebilir \u00e7\u00f6z\u00fcmler sunan g\u00fc\u00e7l\u00fc bir yakla\u015f\u0131m oldu\u011funu g\u00f6stermektedir.<\/p>\n
Peki Durumsuz Yakla\u015f\u0131m\u0131n Zorluklar\u0131 ve \u00c7\u00f6z\u00fcmleri Var m\u0131?<\/h2>\n
Her teknolojik yakla\u015f\u0131m gibi, Model Ba\u011flam Protokol\u00fc’n\u00fcn (MCP) durumsuz mimariyi benimsemesi de beraberinde baz\u0131 zorluklar\u0131 getirir. Bu zorluklar\u0131 anlamak ve bunlara uygun \u00e7\u00f6z\u00fcmler geli\u015ftirmek, ba\u015far\u0131l\u0131 bir implementasyon i\u00e7in kritik \u00f6neme sahiptir. Durumsuzlu\u011fun getirdi\u011fi ba\u015fl\u0131ca zorluklar ve bunlara y\u00f6nelik \u00e7\u00f6z\u00fcm \u00f6nerileri \u015funlard\u0131r:<\/p>\n
1. \u0130stemci Taraf\u0131nda Ba\u011flam Y\u00f6netimi Y\u00fck\u00fc<\/h3>\n
Durumsuz mimaride sunucu, istemcinin ba\u011flam\u0131n\u0131 kendi \u00fczerinde tutmad\u0131\u011f\u0131 i\u00e7in, bu sorumluluk istemciye ge\u00e7er. \u0130stemci, her iste\u011finde gerekli t\u00fcm ba\u011flam bilgilerini (\u00f6rne\u011fin, JWT, oturum kimli\u011fi, kullan\u0131c\u0131 tercihleri) do\u011fru bir \u015fekilde eklemek zorundad\u0131r. Bu durum, istemci taraf\u0131 uygulamas\u0131n\u0131n (web taray\u0131c\u0131s\u0131, mobil uygulama) daha karma\u015f\u0131k hale gelmesine neden olabilir. Ba\u011flam\u0131n g\u00fcvenli bir \u015fekilde saklanmas\u0131, y\u00f6netilmesi ve her istekte do\u011fru bir \u015fekilde iletilmesi, geli\u015ftiriciler i\u00e7in ek bir y\u00fck olu\u015fturur.<\/p>\n
\u00c7\u00f6z\u00fcm:<\/h4>\n\n- K\u00fct\u00fcphaneler ve Frameworkler:<\/strong> Modern web ve mobil geli\u015ftirme frameworkleri (React, Angular, Vue, Flutter, React Native) genellikle durum y\u00f6netimi (state management) i\u00e7in g\u00fc\u00e7l\u00fc ara\u00e7lar ve k\u00fct\u00fcphaneler sunar. Bu ara\u00e7lar, ba\u011flam\u0131n merkezi bir yerde saklanmas\u0131n\u0131 ve kolayca eri\u015filmesini sa\u011flar.<\/li>\n
- API \u0130stemcileri:<\/strong> HTTP isteklerini yapan k\u00fct\u00fcphanelerin (axios, fetch API) araya giren (interceptor) mekanizmalar\u0131 kullan\u0131larak, her iste\u011fe otomatik olarak kimlik do\u011frulama tokenlar\u0131 veya \u00f6zel ba\u015fl\u0131klar eklenebilir. Bu, geli\u015ftiricilerin her istekte manuel olarak ba\u011flam eklemesi ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r.<\/li>\n
- G\u00fcvenli Depolama:<\/strong> Ba\u011flam bilgilerinin (\u00f6zellikle JWT gibi hassas verilerin) istemci taraf\u0131nda g\u00fcvenli bir \u015fekilde (\u00f6rne\u011fin, HTTP Only \u00e7erezler, web storage API, mobil platformlarda g\u00fcvenli anahtar zincirleri) saklanmas\u0131 sa\u011flanmal\u0131d\u0131r.<\/li>\n<\/ul>\n
2. Token G\u00fcvenli\u011fi ve Y\u00f6netimi<\/h3>\n
JWT gibi tokenlar, durumsuz mimarinin temelini olu\u015fturur. Ancak bu tokenlar\u0131n \u00e7al\u0131nmas\u0131 veya k\u00f6t\u00fcye kullan\u0131lmas\u0131, ciddi g\u00fcvenlik riskleri yaratabilir. Token’\u0131n ele ge\u00e7irilmesi durumunda, sald\u0131rgan ge\u00e7erli bir kullan\u0131c\u0131 gibi sisteme eri\u015febilir.<\/p>\n
\u00c7\u00f6z\u00fcm:<\/h4>\n\n- K\u0131sa \u00d6m\u00fcrl\u00fc Tokenlar:<\/strong> JWT’lerin ge\u00e7erlilik s\u00fcreleri k\u0131sa tutulmal\u0131d\u0131r (\u00f6rne\u011fin, 15-30 dakika). Bu, bir token ele ge\u00e7irilse bile, sald\u0131rgan\u0131n s\u0131n\u0131rl\u0131 bir zaman penceresine sahip olmas\u0131n\u0131 sa\u011flar.<\/li>\n
- Yenileme Tokenlar\u0131 (Refresh Tokens):<\/strong> Uzun s\u00fcreli oturumlar i\u00e7in, k\u0131sa \u00f6m\u00fcrl\u00fc eri\u015fim tokenlar\u0131na ek olarak, daha uzun \u00f6m\u00fcrl\u00fc yenileme tokenlar\u0131 kullan\u0131labilir. Eri\u015fim token\u0131 sona erdi\u011finde, istemci yenileme token\u0131n\u0131 kullanarak yeni bir eri\u015fim token\u0131 talep eder. Yenileme tokenlar\u0131 genellikle daha g\u00fcvenli bir \u015fekilde (\u00f6rne\u011fin, HTTP Only \u00e7erezlerde veya sunucu taraf\u0131nda bir veritaban\u0131nda) saklan\u0131r ve tek kullan\u0131ml\u0131k veya IP adresi k\u0131s\u0131tlamal\u0131 olabilir.<\/li>\n
- Token \u0130ptali (Revocation):<\/strong> Durumsuz mimaride token iptali karma\u015f\u0131k olabilir, \u00e7\u00fcnk\u00fc sunucu tokenlar\u0131n ge\u00e7erlili\u011fini kontrol etmek i\u00e7in herhangi bir durum tutmaz. Ancak, bir kara liste (blacklist) veya beyaz liste (whitelist) mekanizmas\u0131 ile bu sa\u011flanabilir. \u0130ptal edilen tokenlar bir veritaban\u0131nda saklanarak her istekte kontrol edilebilir. Bu, tam olarak durumsuz olmasa da, g\u00fcvenlik i\u00e7in kabul edilebilir bir \u00f6d\u00fcnle\u015fim olabilir.<\/li>\n
- HTTPS Kullan\u0131m\u0131:<\/strong> T\u00fcm ileti\u015fim kanallar\u0131 HTTPS ile \u015fifrelenmeli, b\u00f6ylece tokenlar a\u011f \u00fczerinden g\u00fcvenli bir \u015fekilde iletilir.<\/li>\n<\/ul>\n
3. Veri B\u00fct\u00fcnl\u00fc\u011f\u00fc ve Tutarl\u0131l\u0131\u011f\u0131<\/h3>\n
Durumsuz sistemlerde, bir i\u015flem birden fazla ad\u0131mda ger\u00e7ekle\u015fiyorsa ve her ad\u0131mda farkl\u0131 servisler etkile\u015fime giriyorsa, veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc ve tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamak zorla\u015fabilir. \u00d6zellikle bir i\u015flem ba\u015far\u0131s\u0131z oldu\u011funda \u00f6nceki ad\u0131mlar\u0131 geri alma (rollback) mekanizmalar\u0131 daha karma\u015f\u0131k hale gelebilir.<\/p>\n
\u00c7\u00f6z\u00fcm:<\/h4>\n\n- Saga Deseni:<\/strong> Mikroservis mimarilerinde da\u011f\u0131t\u0131k i\u015flemler i\u00e7in Saga deseni kullan\u0131labilir. Bu desende, karma\u015f\u0131k bir i\u015flem birden fazla yerel i\u015flemden olu\u015fur ve her bir yerel i\u015flem kendi veritaban\u0131 \u00fczerinde atomik olarak ger\u00e7ekle\u015ftirilir. E\u011fer bir ad\u0131m ba\u015far\u0131s\u0131z olursa, \u00f6nceki ad\u0131mlar\u0131 geri almak i\u00e7in telafi edici i\u015flemler (compensating transactions) tetiklenir.<\/li>\n
- Olay Kaynaklama (Event Sourcing):<\/strong> T\u00fcm durum de\u011fi\u015fiklikleri bir olay ak\u0131\u015f\u0131 (event stream) olarak saklan\u0131r. Bu, sistemin herhangi bir noktadaki durumunu yeniden olu\u015fturmay\u0131 m\u00fcmk\u00fcn k\u0131lar ve veri tutarl\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r.<\/li>\n
- \u0130dempotent \u0130\u015flemler:<\/strong> API u\u00e7 noktalar\u0131 idempotent (tekrarlanabilir) olacak \u015fekilde tasarlanmal\u0131d\u0131r. Yani, ayn\u0131 iste\u011fin birden fazla kez g\u00f6nderilmesi durumunda bile sistem \u00fczerinde ayn\u0131 sonucu vermesi sa\u011flanmal\u0131d\u0131r. Bu, a\u011f hatalar\u0131 veya tekrar deneme mekanizmalar\u0131 durumunda veri tutarl\u0131l\u0131\u011f\u0131n\u0131 korur.<\/li>\n<\/ul>\n
4. A\u011f Y\u00fck\u00fc<\/h3>\n
Her istekte ba\u011flam bilgilerinin (\u00f6zellikle b\u00fcy\u00fck JWT’ler veya \u00e7ok say\u0131da \u00f6zel ba\u015fl\u0131k) g\u00f6nderilmesi, a\u011f trafi\u011fini art\u0131rabilir ve gecikme s\u00fcresini bir miktar etkileyebilir.<\/p>\n
\u00c7\u00f6z\u00fcm:<\/h4>\n\n- Minimal Ba\u011flam:<\/strong> Tokenlara veya ba\u015fl\u0131klara yaln\u0131zca kesinlikle gerekli olan bilgilerin eklenmesi. Gereksiz verilerden ka\u00e7\u0131nmak.<\/li>\n
- S\u0131k\u0131\u015ft\u0131rma:<\/strong> HTTP s\u0131k\u0131\u015ft\u0131rma (Gzip, Brotli) kullanarak a\u011f \u00fczerinden iletilen verinin boyutunu k\u00fc\u00e7\u00fcltmek.<\/li>\n
- HTTP\/2 ve HTTP\/3:<\/strong> Bu protokoller, ba\u015fl\u0131k s\u0131k\u0131\u015ft\u0131rma (HPACK) ve \u00e7oklama (multiplexing) gibi \u00f6zelliklerle a\u011f performans\u0131n\u0131 art\u0131rarak bu etkiyi azaltabilir.<\/li>\n<\/ul>\n
Durumsuz MCP, sundu\u011fu g\u00fc\u00e7l\u00fc avantajlara ra\u011fmen, bu zorluklar\u0131n fark\u0131nda olunarak ve uygun tasar\u0131m desenleri ile g\u00fcvenlik pratikleri uygulanarak ele al\u0131nmal\u0131d\u0131r. Do\u011fru stratejilerle, durumsuz mimarinin potansiyeli tam olarak ortaya \u00e7\u0131kar\u0131labilir ve kar\u015f\u0131la\u015f\u0131lan engeller a\u015f\u0131labilir.<\/p>\n
Ger\u00e7ek D\u00fcnya Senaryolar\u0131nda Durumsuz MCP Uygulamalar\u0131<\/h2>\n
Model Ba\u011flam Protokol\u00fc’n\u00fcn (MCP) durumsuz mimariyi benimsemesi, modern yaz\u0131l\u0131m ekosisteminde geni\u015f bir uygulama alan\u0131na sahiptir. \u00d6zellikle da\u011f\u0131t\u0131k sistemler, bulut tabanl\u0131 platformlar ve mikroservis mimarileri, bu yakla\u015f\u0131m\u0131n sundu\u011fu esneklik ve \u00f6l\u00e7eklenebilirlikten b\u00fcy\u00fck \u00f6l\u00e7\u00fcde faydalan\u0131r. \u0130\u015fte durumsuz MCP’nin ger\u00e7ek d\u00fcnya senaryolar\u0131nda nas\u0131l kullan\u0131ld\u0131\u011f\u0131na dair baz\u0131 \u00f6rnekler:<\/p>\n
1. Mikroservis Mimarileri<\/h3>\n
Mikroservisler, b\u00fcy\u00fck bir uygulaman\u0131n ba\u011f\u0131ms\u0131z, k\u00fc\u00e7\u00fck ve kendi i\u00e7inde \u00e7al\u0131\u015fan servislerden olu\u015ftu\u011fu bir mimari yakla\u015f\u0131md\u0131r. Her servis kendi veritaban\u0131na sahip olabilir ve kendi i\u015f mant\u0131\u011f\u0131n\u0131 y\u00fcr\u00fct\u00fcr. Bu ortamda, bir kullan\u0131c\u0131n\u0131n iste\u011fi genellikle birden fazla servisten ge\u00e7er. Durumsuz MCP, bu servisler aras\u0131nda ba\u011flam bilgisinin (kullan\u0131c\u0131 kimli\u011fi, yetkileri, i\u015flem kimli\u011fi vb.) tutarl\u0131 ve g\u00fcvenli bir \u015fekilde ta\u015f\u0131nmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, bir sipari\u015f verme i\u015flemi, \u00f6nce kimlik do\u011frulama servisine, ard\u0131ndan \u00fcr\u00fcn katalo\u011fu servisine, stok servisine ve son olarak \u00f6deme servisine gidebilir. Her servis, istekle birlikte gelen JWT veya \u00f6zel HTTP ba\u015fl\u0131klar\u0131 arac\u0131l\u0131\u011f\u0131yla kullan\u0131c\u0131n\u0131n ba\u011flam\u0131na eri\u015fir ve kendi i\u015fini yapar. Bu durum, servislerin birbirlerinden ba\u011f\u0131ms\u0131z kalmas\u0131n\u0131 ve ayr\u0131 ayr\u0131 \u00f6l\u00e7eklenebilmesini sa\u011flar.<\/p>\n
2. Sunucusuz (Serverless) Fonksiyonlar<\/h3>\n
AWS Lambda, Azure Functions veya Google Cloud Functions gibi sunucusuz platformlar, durumsuz mimarinin en saf hallerinden birini temsil eder. Bu fonksiyonlar, yaln\u0131zca bir olay (\u00f6rne\u011fin, bir HTTP iste\u011fi, bir veritaban\u0131 de\u011fi\u015fikli\u011fi) tetiklendi\u011finde \u00e7al\u0131\u015f\u0131r ve i\u015flerini bitirdiklerinde kaynaklar\u0131 serbest b\u0131rak\u0131r. Her fonksiyon \u00e7a\u011fr\u0131s\u0131 tamamen ba\u011f\u0131ms\u0131zd\u0131r ve \u00f6nceki \u00e7a\u011fr\u0131lar hakk\u0131nda hi\u00e7bir bilgiye sahip de\u011fildir. Durumsuz MCP, bu ortamda ba\u011flam y\u00f6netimini standartla\u015ft\u0131r\u0131r. Bir API Gateway \u00fczerinden gelen istekler, gerekli ba\u011flam bilgilerini (\u00f6rne\u011fin, kimlik do\u011frulama tokenlar\u0131) sunucusuz fonksiyona iletir. Fonksiyon, bu ba\u011flam\u0131 kullanarak i\u015fini yapar ve bir yan\u0131t d\u00f6nd\u00fcr\u00fcr. Bu sayede, geli\u015ftiriciler altyap\u0131 y\u00f6netimiyle u\u011fra\u015fmadan i\u015f mant\u0131\u011f\u0131na odaklanabilirler.<\/p>\n
3. API Gateway’ler<\/h3>\n
API Gateway’ler, istemcilerden gelen t\u00fcm API istekleri i\u00e7in tek bir giri\u015f noktas\u0131 g\u00f6revi g\u00f6r\u00fcr. Bu gateway’ler, istekleri ilgili mikroservislere y\u00f6nlendirmeden \u00f6nce kimlik do\u011frulama, yetkilendirme, h\u0131z s\u0131n\u0131rlama (rate limiting) ve ba\u011flam d\u00f6n\u00fc\u015ft\u00fcrme gibi i\u015flemleri ger\u00e7ekle\u015ftirebilir. Durumsuz MCP, API Gateway’lerin bu s\u00fcre\u00e7leri daha verimli y\u00f6netmesini sa\u011flar. Gateway, gelen istekteki JWT’yi do\u011frulayabilir, kullan\u0131c\u0131 bilgilerini \u00e7\u0131karabilir ve bu bilgileri \u00f6zel ba\u015fl\u0131klar arac\u0131l\u0131\u011f\u0131yla a\u015fa\u011f\u0131 ak\u0131\u015f (downstream) servislerine iletebilir. Bu, her mikroservisin kendi kimlik do\u011frulama ve yetkilendirme mant\u0131\u011f\u0131n\u0131 tekrar yazma ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r ve g\u00fcvenlik politikalar\u0131n\u0131n merkezi bir noktadan uygulanmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r.<\/p>\n
4. Mobil ve Web Uygulamalar\u0131<\/h3>\n
Modern mobil ve web uygulamalar\u0131, genellikle RESTful API’ler veya GraphQL API’ler arac\u0131l\u0131\u011f\u0131yla arka u\u00e7 (backend) servisleriyle ileti\u015fim kurar. Bu uygulamalar\u0131n kullan\u0131c\u0131 deneyimini kesintisiz k\u0131lmak i\u00e7in h\u0131zl\u0131 ve g\u00fcvenilir bir ba\u011flam y\u00f6netimine ihtiyac\u0131 vard\u0131r. Durumsuz MCP, mobil ve web istemcilerinin sunucu taraf\u0131nda oturum tutmadan kimlik do\u011frulamal\u0131 ve yetkilendirmeli istekler yapmas\u0131n\u0131 sa\u011flar. Kullan\u0131c\u0131 bir kez giri\u015f yapt\u0131\u011f\u0131nda ald\u0131\u011f\u0131 JWT’yi g\u00fcvenli bir \u015fekilde saklar ve sonraki t\u00fcm API isteklerinde bu token\u0131 g\u00f6nderir. Bu, kullan\u0131c\u0131 oturumlar\u0131n\u0131n cihazlar aras\u0131nda bile kolayca ta\u015f\u0131nabilmesini sa\u011flar ve \u00e7evrimd\u0131\u015f\u0131 (offline) yeteneklerin geli\u015ftirilmesini kolayla\u015ft\u0131r\u0131r.<\/p>\n
Kod \u00d6rne\u011fi: JWT ile Durumsuz Kimlik Do\u011frulama<\/h3>\n
A\u015fa\u011f\u0131da, bir Node.js Express uygulamas\u0131nda JWT kullanarak durumsuz bir kimlik do\u011frulama ara yaz\u0131l\u0131m\u0131 (middleware) \u00f6rne\u011fi bulunmaktad\u0131r. Bu, gelen istekteki JWT’yi do\u011frulayarak kullan\u0131c\u0131n\u0131n ba\u011flam\u0131n\u0131 iste\u011fe ekler ve b\u00f6ylece di\u011fer rotalar\u0131n bu bilgiye eri\u015fmesini sa\u011flar.<\/p>\n
\n\nconst express = require('express');\nconst jwt = require('jsonwebtoken');\nconst app = express();\nconst SECRET_KEY = \"cok_gizli_anahtar\"; \/\/ Ger\u00e7ek uygulamada ortam de\u011fi\u015fkeninden al\u0131nmal\u0131\n\n\/\/ JWT do\u011frulama ara yaz\u0131l\u0131m\u0131\nfunction authenticateToken(req, res, next) {\n const authHeader = req.headers['authorization'];\n const token = authHeader && authHeader.split(' ')[1]; \/\/ Bearer TOKEN\n\n if (token == null) return res.sendStatus(401); \/\/ Token yoksa yetkisiz\n\n jwt.verify(token, SECRET_KEY, (err, user) => {\n if (err) return res.sendStatus(403); \/\/ Token ge\u00e7ersizse yasak\n req.user = user; \/\/ Kullan\u0131c\u0131 ba\u011flam\u0131n\u0131 iste\u011fe ekle\n next();\n });\n}\n\napp.use(express.json());\n\n\/\/ Giri\u015f rotas\u0131 - JWT olu\u015fturur\napp.post('\/login', (req, res) => {\n const { username, password } = req.body;\n \/\/ Ger\u00e7ek bir uygulamada veritaban\u0131ndan kullan\u0131c\u0131 do\u011frulamas\u0131 yap\u0131l\u0131r\n if (username === 'testuser' && password === 'password123') {\n const user = { userId: '1', username: 'testuser', role: 'admin' };\n const accessToken = jwt.sign(user, SECRET_KEY, { expiresIn: '15m' });\n res.json({ accessToken: accessToken });\n } else {\n res.status(401).send('Kullan\u0131c\u0131 ad\u0131 veya \u015fifre hatal\u0131');\n }\n});\n\n\/\/ Korunan rota - authenticateToken ara yaz\u0131l\u0131m\u0131 ile korunur\napp.get('\/profile', authenticateToken, (req, res) => {\n res.json({ message: Ho\u015f geldin, ${req.user.username}! Rol\u00fcn: ${req.user.role}<\/code> });\n});\n\nconst PORT = 3000;\napp.listen(PORT, () => {\n console.log(Sunucu http:\/\/localhost:${PORT} adresinde \u00e7al\u0131\u015f\u0131yor<\/code>);\n});\n <\/code><\/pre>\n<\/p><\/div>\nBu \u00f6rnekte, authenticateToken<\/code> ara yaz\u0131l\u0131m\u0131, gelen her iste\u011fin Authorization<\/code> ba\u015fl\u0131\u011f\u0131ndaki JWT’yi kontrol eder. E\u011fer token ge\u00e7erliyse, token i\u00e7indeki kullan\u0131c\u0131 bilgilerini (ba\u011flam\u0131) req.user<\/code> nesnesine ekler. B\u00f6ylece, \/profile<\/code> rotas\u0131 gibi korunan rotalar, sunucunun herhangi bir oturum tutmas\u0131na gerek kalmadan, do\u011frudan bu ba\u011flam bilgisine eri\u015febilir. Bu, durumsuz MCP’nin pratik bir uygulamas\u0131d\u0131r ve modern API tasar\u0131mlar\u0131n\u0131n temelini olu\u015fturur.<\/p>\nGelecekte Model Ba\u011flam Protokol\u00fc ve Durumsuz Mimarinin Yeri Neresi Olacak?<\/h2>\n
Dijital d\u00f6n\u00fc\u015f\u00fcm\u00fcn h\u0131z kesmeden devam etti\u011fi bir \u00e7a\u011fda, yaz\u0131l\u0131m sistemlerinden beklentiler s\u00fcrekli artmaktad\u0131r. Kullan\u0131c\u0131lar anl\u0131k yan\u0131tlar, kesintisiz hizmet ve ki\u015fiselle\u015ftirilmi\u015f deneyimler talep ederken, i\u015fletmeler de maliyet etkinli\u011fi, h\u0131zl\u0131 inovasyon ve kolay \u00f6l\u00e7eklenebilirlik pe\u015findedir. Model Ba\u011flam Protokol\u00fc’n\u00fcn (MCP) durumsuz mimariyi benimsemesi, bu beklentilere yan\u0131t veren ve gelece\u011fin yaz\u0131l\u0131m mimarilerini \u015fekillendirecek temel yakla\u015f\u0131mlardan biri olarak \u00f6ne \u00e7\u0131kmaktad\u0131r.<\/p>\n
Gelecekte, bulut bili\u015fim (cloud computing) ve sunucusuz (serverless) teknolojilerin daha da yayg\u0131nla\u015fmas\u0131yla birlikte, durumsuz mimarinin \u00f6nemi katlanarak artacakt\u0131r. Geleneksel durum bilgili sistemlerin getirdi\u011fi karma\u015f\u0131kl\u0131k, \u00f6l\u00e7eklenebilirlik sorunlar\u0131 ve y\u00fcksek i\u015fletme maliyetleri, geli\u015ftiricileri ve mimarlar\u0131 ka\u00e7\u0131n\u0131lmaz olarak durumsuz \u00e7\u00f6z\u00fcmlere y\u00f6nlendirecektir. MCP, bu ge\u00e7i\u015fi kolayla\u015ft\u0131ran ve standartla\u015ft\u0131ran bir k\u00f6pr\u00fc g\u00f6revi g\u00f6recektir. \u00d6zellikle \u00e7oklu bulut (multi-cloud) ve hibrit bulut (hybrid cloud) ortamlar\u0131nda, farkl\u0131 platformlar ve servisler aras\u0131nda ba\u011flam\u0131n tutarl\u0131 bir \u015fekilde ta\u015f\u0131nabilmesi, MCP gibi standartla\u015ft\u0131r\u0131lm\u0131\u015f protokollere olan ihtiyac\u0131 daha da belirgin hale getirecektir.<\/p>\n
Yapay zeka (AI) ve makine \u00f6\u011frenimi (ML) modellerinin i\u015f s\u00fcre\u00e7lerine entegrasyonu da durumsuz MCP i\u00e7in yeni f\u0131rsatlar sunmaktad\u0131r. Bir AI modeline yap\u0131lan her istek, modelin kendisi i\u00e7in durumsuz bir ba\u011flam ta\u015f\u0131yabilir; \u00f6rne\u011fin, kullan\u0131c\u0131n\u0131n ge\u00e7mi\u015f tercihleri veya mevcut sorguyla ilgili ek bilgiler. Bu, AI modellerinin daha ki\u015fiselle\u015ftirilmi\u015f ve ba\u011flama duyarl\u0131 yan\u0131tlar \u00fcretmesini sa\u011flayabilir. Ayr\u0131ca, nesnelerin interneti (IoT) cihazlar\u0131ndan gelen milyarlarca veri noktas\u0131n\u0131n i\u015flenmesi gereken senaryolarda, durumsuz mimarinin sundu\u011fu y\u00fcksek performans ve \u00f6l\u00e7eklenebilirlik, veri ak\u0131\u015flar\u0131n\u0131n etkin bir \u015fekilde y\u00f6netilmesi i\u00e7in kritik olacakt\u0131r.<\/p>\n
G\u00fcvenlik alan\u0131nda da MCP’nin rol\u00fc artmaya devam edecektir. Da\u011f\u0131t\u0131k sistemlerde kimlik do\u011frulama ve yetkilendirme y\u00f6netimi, merkezi ve durum bilgili yakla\u015f\u0131mlarla giderek zorla\u015fmaktad\u0131r. Durumsuz token tabanl\u0131 yakla\u015f\u0131mlar, g\u00fcvenlik politikalar\u0131n\u0131n daha esnek ve dinamik bir \u015fekilde uygulanmas\u0131na olanak tan\u0131r. Ancak, token y\u00f6netimi, yenileme mekanizmalar\u0131 ve token iptali gibi konular\u0131n daha da olgunla\u015fmas\u0131 ve standartla\u015fmas\u0131 gerekecektir. MCP, bu alandaki en iyi pratiklerin ve standartlar\u0131n benimsenmesine \u00f6nc\u00fcl\u00fck edebilir.<\/p>\n
\u00d6zetle, Model Ba\u011flam Protokol\u00fc’n\u00fcn durumsuz mimariyi benimsemesi, sadece mevcut sorunlara bir \u00e7\u00f6z\u00fcm sunmakla kalm\u0131yor, ayn\u0131 zamanda gelece\u011fin yaz\u0131l\u0131m ekosisteminin temel yap\u0131 ta\u015flar\u0131ndan biri olma potansiyelini ta\u015f\u0131yor. \u00d6l\u00e7eklenebilir, esnek, g\u00fcvenilir ve performansl\u0131 sistemler in\u015fa etme ihtiyac\u0131 devam ettik\u00e7e, durumsuz ba\u011flam y\u00f6netiminin \u00f6nemi artacak ve MCP gibi protokoller, bu alandaki standartlar\u0131 belirleyecektir. Geli\u015ftiricilerin bu prensipleri anlamas\u0131 ve uygulamalar\u0131na entegre etmesi, onlar\u0131 gelece\u011fin dijital d\u00fcnyas\u0131na haz\u0131rlayacakt\u0131r.<\/p>\n
S\u0131k\u00e7a Sorulan Sorular<\/h2>\n1. Durumsuz mimaride oturum y\u00f6netimi nas\u0131l yap\u0131l\u0131r?<\/h3>\n
Durumsuz mimaride sunucu taraf\u0131nda geleneksel “oturum” kavram\u0131 bulunmaz. Bunun yerine, istemci taraf\u0131nda y\u00f6netilen tokenlar (\u00f6rne\u011fin, JWT) kullan\u0131l\u0131r. Kullan\u0131c\u0131 kimlik do\u011frulamas\u0131ndan sonra bir token al\u0131r ve bu token\u0131 sonraki her iste\u011finde HTTP ba\u015fl\u0131\u011f\u0131 arac\u0131l\u0131\u011f\u0131yla sunucuya g\u00f6nderir. Sunucu, bu token\u0131 do\u011frulayarak kullan\u0131c\u0131n\u0131n kimli\u011fini ve yetkilerini anlar. Oturum s\u00fcresi, token\u0131n ge\u00e7erlilik s\u00fcresi ile s\u0131n\u0131rl\u0131d\u0131r ve uzun s\u00fcreli oturumlar i\u00e7in yenileme tokenlar\u0131 (refresh tokens) kullan\u0131labilir.<\/p>\n
2. Model Ba\u011flam Protokol\u00fc sadece web API’leri i\u00e7in mi ge\u00e7erlidir?<\/h3>\n
Hay\u0131r, Model Ba\u011flam Protokol\u00fc (MCP) prensipleri sadece web API’leri ile s\u0131n\u0131rl\u0131 de\u011fildir. Mikroservisler aras\u0131 ileti\u015fim, sunucusuz fonksiyonlar, IoT cihazlar\u0131 ve hatta masa\u00fcst\u00fc uygulamalar\u0131 gibi farkl\u0131 da\u011f\u0131t\u0131k sistem bile\u015fenleri aras\u0131nda ba\u011flam y\u00f6netimini standartla\u015ft\u0131rmak i\u00e7in kullan\u0131labilir. Temel ama\u00e7, ba\u011flam\u0131n tutarl\u0131 ve g\u00fcvenli bir \u015fekilde ta\u015f\u0131nmas\u0131n\u0131 sa\u011flamakt\u0131r, ileti\u015fim protokol\u00fcnden ba\u011f\u0131ms\u0131z olarak.<\/p>\n
3. Durumsuz mimarinin performansa olumsuz bir etkisi olabilir mi?<\/h3>\n
Her istekte ba\u011flam bilgilerinin (\u00f6zellikle b\u00fcy\u00fck tokenlar veya \u00e7ok say\u0131da ba\u015fl\u0131k) g\u00f6nderilmesi, a\u011f trafi\u011fini bir miktar art\u0131rabilir. Ancak, genellikle bu art\u0131\u015f, durum bilgili sistemlerdeki oturum y\u00f6netimi, replikasyon ve sunucu taraf\u0131 durum tutma y\u00fck\u00fcn\u00fcn getirdi\u011fi performans darbo\u011fazlar\u0131na k\u0131yasla ihmal edilebilir d\u00fczeydedir. Do\u011fru optimize edilmi\u015f tokenlar ve HTTP\/2 gibi modern protokoller kullan\u0131ld\u0131\u011f\u0131nda, durumsuz mimari genellikle daha iyi genel performans sunar.<\/p>\n
4. Durumsuz MCP’de hata ay\u0131klama (debugging) daha m\u0131 zordur?<\/h3>\n
Durumsuz sistemlerde, her istek ba\u011f\u0131ms\u0131z oldu\u011fu i\u00e7in, bir i\u015flemin farkl\u0131 servisler aras\u0131nda nas\u0131l ilerledi\u011fini takip etmek ilk ba\u015fta zorlay\u0131c\u0131 olabilir. Ancak, da\u011f\u0131t\u0131k izleme (distributed tracing) ara\u00e7lar\u0131 (\u00f6rne\u011fin, OpenTelemetry, Jaeger, Zipkin) ve merkezi loglama (centralized logging) sistemleri bu sorunu \u00e7\u00f6zmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Bu ara\u00e7lar, bir iste\u011fin sistemdeki yolculu\u011funu g\u00f6steren benzersiz i\u015flem kimlikleri (correlation IDs) kullanarak, hata ay\u0131klama s\u00fcrecini kolayla\u015ft\u0131r\u0131r.<\/p>\n
#Teknoloji #WebGeli\u015ftirme #DurumsuzMimari #ModelBa\u011flamProtokol\u00fc #API #Mikroservisler #BulutBili\u015fim<\/p>\n