M\u00fchendislik m\u00fclakatlar\u0131n\u0131n en zorlu a\u015famalar\u0131ndan biri olan sistem tasar\u0131m\u0131 sorular\u0131, \u00e7o\u011fu zaman basit g\u00f6r\u00fcnen ama derinlemesine bilgi ve deneyim gerektiren tuzaklar bar\u0131nd\u0131r\u0131r. Pek \u00e7ok m\u00fchendisin be\u015f dakikada \u00e7\u00f6zd\u00fc\u011f\u00fcn\u00fc d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fc ancak asl\u0131nda kritik detaylar\u0131 g\u00f6zden ka\u00e7\u0131rd\u0131\u011f\u0131 bu sorular, teknik bilginin \u00f6tesinde problem \u00e7\u00f6zme ve mimari d\u00fc\u015f\u00fcnme becerilerini \u00f6l\u00e7er. Bu makalede, TinyURL benzeri bir URL k\u0131saltma servisinin tasar\u0131m\u0131n\u0131 ad\u0131m ad\u0131m ele alarak, bu t\u00fcr “5 dakikal\u0131k” sorular\u0131n alt\u0131nda yatan karma\u015f\u0131kl\u0131klar\u0131 ve do\u011fru yakla\u015f\u0131m\u0131 ke\u015ffedece\u011fiz. Haz\u0131r olun, \u00e7\u00fcnk\u00fc bu makale size sadece bir sistemi nas\u0131l tasarlayaca\u011f\u0131n\u0131z\u0131 de\u011fil, ayn\u0131 zamanda sistem tasar\u0131m m\u00fclakatlar\u0131nda nas\u0131l ba\u015far\u0131l\u0131 olaca\u011f\u0131n\u0131z\u0131 da g\u00f6sterecek.<\/p>\n
Sistem tasar\u0131m\u0131 m\u00fclakatlar\u0131, adaylar\u0131n geni\u015f bir m\u00fchendislik problemini ele alma, yap\u0131land\u0131rma ve \u00e7\u00f6zme yeteneklerini de\u011ferlendirmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. “5 dakikal\u0131k” tabiri, sorunun y\u00fczeysel olarak basit g\u00f6r\u00fcnmesinden gelir; \u00f6rne\u011fin, “TinyURL gibi bir servis tasarlay\u0131n” veya “Bir sohbet uygulamas\u0131 tasarlay\u0131n.” Ancak, bu basit g\u00f6r\u00fcnen sorular\u0131n alt\u0131nda yatan beklentiler, genellikle bir m\u00fchendisin hayal edebilece\u011finden \u00e7ok daha fazlas\u0131n\u0131 i\u00e7erir. M\u00fchendislerin bu t\u00fcr sorularda yan\u0131lmalar\u0131n\u0131n bir\u00e7ok nedeni vard\u0131r ve bunlar\u0131n \u00e7o\u011fu, teknik bilgiden ziyade metodolojik yakla\u015f\u0131mdaki eksikliklerden kaynaklan\u0131r. \u00d6ncelikle, \u00e7o\u011fu aday m\u00fclakat\u0131n ba\u015f\u0131nda yeterince ayd\u0131nlat\u0131c\u0131 soru sormaz<\/b>. Gereksinimleri tam olarak anlamadan, kapsam\u0131 belirlemeden do\u011frudan \u00e7\u00f6z\u00fcm \u00fcretmeye \u00e7al\u0131\u015fmak, ba\u015ftan yanl\u0131\u015f bir yola girmeye neden olur. \u00d6rne\u011fin, URL k\u0131saltma servisi tasarlarken, hangi throughput (i\u015flem hacmi) bekleniyor, k\u0131sa URL’lerin ge\u00e7erlilik s\u00fcresi olacak m\u0131, yoksa sadece kal\u0131c\u0131 m\u0131 olacaklar gibi sorular, sistemin temel mimarisini k\u00f6kten de\u011fi\u015ftirebilir.<\/p>\n
\u0130kinci olarak, m\u00fchendisler genellikle fonksiyonel gereksinimlere odaklan\u0131p, non-fonksiyonel gereksinimleri g\u00f6z ard\u0131 ederler<\/b>. Bir sistemin sadece “\u00e7al\u0131\u015fmas\u0131” yeterli de\u011fildir; ayn\u0131 zamanda y\u00fcksek \u00f6l\u00e7eklenebilirlik, d\u00fc\u015f\u00fck gecikme, y\u00fcksek eri\u015filebilirlik, veri tutarl\u0131l\u0131\u011f\u0131 ve g\u00fcvenlik gibi \u00f6zelliklere de sahip olmas\u0131 gerekir. TinyURL \u00f6rne\u011finde, saniyede binlerce k\u0131saltma iste\u011fini veya milyonlarca y\u00f6nlendirme iste\u011fini kar\u015f\u0131layabilmek, temel bir veritaban\u0131 \u015femas\u0131ndan \u00e7ok daha fazlas\u0131n\u0131 gerektirir. Bu kritik performans ve g\u00fcvenilirlik hedefleri belirlenmeden yap\u0131lan bir tasar\u0131m, ger\u00e7ek d\u00fcnyada h\u0131zla \u00e7\u00f6kecek veya bak\u0131m\u0131 imkans\u0131z hale gelecektir. Bu y\u00fczden, m\u00fclakat s\u0131ras\u0131nda bu non-fonksiyonel gereksinimlerin kapsam\u0131n\u0131 ve \u00f6nceliklerini netle\u015ftirmek hayati \u00f6nem ta\u015f\u0131r. Ayr\u0131ca, m\u00fchendisler s\u0131k\u00e7a trade-off’lar\u0131 (takaslar\u0131) g\u00f6z \u00f6n\u00fcnde bulundurmazlar<\/b>. Da\u011f\u0131t\u0131k sistem tasar\u0131m\u0131nda her karar\u0131n bir bedeli vard\u0131r. Bir sistemi daha eri\u015filebilir yapmak, genellikle tutarl\u0131l\u0131ktan \u00f6d\u00fcn vermek anlam\u0131na gelebilir (CAP teoremi). Veri depolama se\u00e7imi, \u00f6nbellekleme stratejileri veya kimlik olu\u015fturma mekanizmalar\u0131 gibi kararlar, sistemin genel performans\u0131, maliyeti ve karma\u015f\u0131kl\u0131\u011f\u0131 \u00fczerinde do\u011frudan etki yapar. Bu takaslar\u0131 anlay\u0131p, m\u00fclakat\u00e7\u0131ya sunabilmek, yaln\u0131zca teknik bilginizi de\u011fil, ayn\u0131 zamanda olgun ve pragmatik bir m\u00fchendislik yakla\u015f\u0131m\u0131n\u0131z\u0131 da g\u00f6sterir.<\/p>\n
Son olarak, bir\u00e7ok m\u00fchendis \u00e7ok erken detaylara tak\u0131l\u0131r veya y\u00fcksek seviye bir bak\u0131\u015f a\u00e7\u0131s\u0131 geli\u015ftiremez<\/b>. Bir sistem tasar\u0131m\u0131na ba\u015flarken, geni\u015f resmi g\u00f6rmek ve ana bile\u015fenleri belirlemek \u00e7ok \u00f6nemlidir. Mikroservis mimarisine mi gidiyoruz, monolitik mi kalacak? Hangi veri depolar\u0131n\u0131 kullanaca\u011f\u0131z? Y\u00fck dengeleme nas\u0131l yap\u0131lacak? Bu sorular\u0131n cevab\u0131, daha sonraki detayl\u0131 tasar\u0131m ad\u0131mlar\u0131 i\u00e7in bir yol haritas\u0131 sunar. Ancak baz\u0131 adaylar, ilk dakikalardan itibaren bir veritaban\u0131n\u0131n hangi indekslerini kullanacaklar\u0131n\u0131 veya belirli bir kod par\u00e7as\u0131n\u0131 nas\u0131l yazacaklar\u0131n\u0131 d\u00fc\u015f\u00fcnmeye ba\u015flarlar. Bu durum, genel mimariyi g\u00f6zden ka\u00e7\u0131rmaya ve sistemin b\u00fct\u00fcnsel resmini kaybetmeye yol a\u00e7ar. \u00d6zetle, “5 dakikal\u0131k” sistem tasar\u0131m\u0131 sorular\u0131, sadece teknik bilgi birikimini de\u011fil, ayn\u0131 zamanda structured thinking (yap\u0131land\u0131r\u0131lm\u0131\u015f d\u00fc\u015f\u00fcnme), problem \u00e7\u00f6zme, ileti\u015fim ve m\u00fchendislik yarg\u0131s\u0131 gibi bir\u00e7ok \u00f6nemli beceriyi test eder. Bu nedenle, ba\u015far\u0131l\u0131 olmak i\u00e7in bu alanlarda da kendinizi geli\u015ftirmeniz \u015fartt\u0131r.<\/p>\nTemel Kavramlar: Bir Sistem Tasar\u0131m\u0131nda Neleri Bilmeliyiz?<\/h2>\n
Sistem tasar\u0131m\u0131na giri\u015f yaparken, baz\u0131 temel kavramlar\u0131 ve prensipleri sa\u011flam bir \u015fekilde anlamak gereklidir. Bu kavramlar, herhangi bir karma\u015f\u0131k sistemi ele al\u0131rken bir \u00e7er\u00e7eve sunar ve do\u011fru sorular\u0131 sorman\u0131za yard\u0131mc\u0131 olur. \u00d6zellikle da\u011f\u0131t\u0131k sistemlerin dinamik do\u011fas\u0131, bu temel prensiplerin \u00f6nemini daha da art\u0131r\u0131r. Bir projeye ba\u015flarken veya bir m\u00fclakat sorusunu yan\u0131tlarken, \u00f6ncelikle projenin temel ta\u015flar\u0131n\u0131 do\u011fru bir \u015fekilde belirlemelisiniz.<\/p>\n
Bir sistemin ne yapaca\u011f\u0131n\u0131 ve bunu nas\u0131l yapaca\u011f\u0131n\u0131 belirlemek, tasar\u0131m s\u00fcrecinin ilk ve en kritik ad\u0131m\u0131d\u0131r. Fonksiyonel gereksinimler<\/b>, sistemin “ne” yapmas\u0131 gerekti\u011fini tan\u0131mlar; yani son kullan\u0131c\u0131n\u0131n g\u00f6z\u00fcnden g\u00f6r\u00fclen \u00f6zellikleri ifade ederler. TinyURL \u00f6rne\u011finde fonksiyonel gereksinimler \u015funlar olabilir:<\/p>\n \u00d6te yandan, non-fonksiyonel gereksinimler<\/b>, sistemin “nas\u0131l” \u00e7al\u0131\u015fmas\u0131 gerekti\u011fini, yani performans, g\u00fcvenilirlik, \u00f6l\u00e7eklenebilirlik gibi kalite \u00f6zelliklerini tan\u0131mlar. Bunlar, kullan\u0131c\u0131n\u0131n do\u011frudan etkile\u015fimde bulunmad\u0131\u011f\u0131 ancak sistemin genel deneyimini ve s\u00fcrd\u00fcr\u00fclebilirli\u011fini belirleyen fakt\u00f6rlerdir. TinyURL i\u00e7in non-fonksiyonel gereksinimler ise \u015funlar olabilir:<\/p>\n Bu gereksinimleri ba\u015ftan net bir \u015fekilde belirlemek ve m\u00fclakat\u00e7\u0131 ile mutab\u0131k kalmak, tasar\u0131m\u0131n\u0131z\u0131n temelini olu\u015fturur ve ilerleyen ad\u0131mlarda yanl\u0131\u015f kararlar alman\u0131z\u0131n \u00f6n\u00fcne ge\u00e7er. Aksi takdirde, gereksinimler belirsiz kald\u0131\u011f\u0131nda, tasar\u0131m\u0131n\u0131z ne kadar teknik olarak kusursuz olursa olsun, m\u00fclakat\u00e7\u0131n\u0131n beklentilerini kar\u015f\u0131lamayabilir.<\/p>\n Modern sistem tasar\u0131mlar\u0131, genellikle belirli g\u00f6revleri yerine getiren \u00e7e\u015fitli bile\u015fenlerden olu\u015fur. Bu bile\u015fenleri ve rollerini anlamak, karma\u015f\u0131k bir sistemi par\u00e7alara ay\u0131rarak tasarlaman\u0131za yard\u0131mc\u0131 olur:<\/p>\n Bu bile\u015fenlerin her biri, sistemin belirli bir ihtiyac\u0131n\u0131 kar\u015f\u0131lamak \u00fczere tasarlanm\u0131\u015ft\u0131r. Do\u011fru bile\u015fenleri se\u00e7mek ve bunlar\u0131 etkili bir \u015fekilde bir araya getirmek, ba\u015far\u0131l\u0131 bir sistem tasar\u0131m\u0131n\u0131n anahtar\u0131d\u0131r. \u00d6zellikle bir “5 dakikal\u0131k” soruda, hangi bile\u015fenlerin neden se\u00e7ildi\u011fini ve birbirleriyle nas\u0131l etkile\u015fime girdiklerini a\u00e7\u0131klamak, m\u00fclakat\u00e7\u0131y\u0131 etkileyecektir.<\/p>\n Art\u0131k teorik bilgileri edindi\u011fimize g\u00f6re, TinyURL benzeri bir URL k\u0131saltma servisinin tasar\u0131m\u0131n\u0131 pratik bir senaryo \u00fczerinden ad\u0131m ad\u0131m ele alal\u0131m. Bu b\u00f6l\u00fcmde, bir sistem tasar\u0131m m\u00fclakat\u0131nda nas\u0131l d\u00fc\u015f\u00fcnece\u011finizi ve sorular\u0131 nas\u0131l yap\u0131land\u0131raca\u011f\u0131n\u0131z\u0131 g\u00f6receksiniz. Ama\u00e7, sadece bir \u00e7\u00f6z\u00fcm sunmak de\u011fil, ayn\u0131 zamanda d\u00fc\u015f\u00fcnme s\u00fcrecinizi ve tasar\u0131m kararlar\u0131n\u0131z\u0131n ard\u0131ndaki mant\u0131\u011f\u0131 g\u00f6stermektir.<\/p>\n M\u00fclakat\u00e7\u0131 size “TinyURL benzeri bir servis tasarlay\u0131n” dedi\u011finde, ilk tepkiniz do\u011frudan kod yazmaya veya veritaban\u0131 \u015femas\u0131 \u00e7izmeye ba\u015flamak olmamal\u0131d\u0131r. Bunun yerine, kapsam\u0131 ve gereksinimleri netle\u015ftirmek i\u00e7in sorular sormaya ba\u015flamal\u0131s\u0131n\u0131z. Bu a\u015fama, t\u00fcm tasar\u0131m s\u00fcrecinin en \u00f6nemli k\u0131sm\u0131d\u0131r ve genellikle g\u00f6z ard\u0131 edilir.<\/p>\n \u00d6rnek sorular:<\/p>\n Bu sorular\u0131n cevaplar\u0131, sistemin boyutunu, kullan\u0131lacak teknolojileri ve mimari desenleri do\u011frudan etkiler. \u00d6rne\u011fin, saniyede 10.000 y\u00f6nlendirme iste\u011fi, \u00e7ok h\u0131zl\u0131 bir \u00f6nbellek katman\u0131 ve da\u011f\u0131t\u0131k bir veritaban\u0131 gerektirecektir. 6-8 karakterlik k\u0131sa URL’ler, benzersiz kimlikler \u00fcretme stratejisini belirleyecektir. Custom URL’ler ise, var olan k\u0131saltmalarla \u00e7ak\u0131\u015fma kontrol\u00fc gerektirecektir.<\/p>\n Varsayal\u0131m ki m\u00fclakat\u00e7\u0131dan a\u015fa\u011f\u0131daki gereksinimleri ald\u0131k:<\/p>\n Gereksinimleri netle\u015ftirdikten sonra, sistemin y\u00fcksek seviye mimarisini \u00e7izmeye ba\u015flayabilirsiniz. Bu a\u015famada, temel bile\u015fenleri ve bunlar\u0131n birbirleriyle nas\u0131l etkile\u015fimde bulunaca\u011f\u0131n\u0131 belirleriz. Ama\u00e7, sistemin genel yap\u0131s\u0131n\u0131 ortaya koymakt\u0131r, hen\u00fcz detaylara inmeyiz.<\/p>\n TinyURL i\u00e7in ana bile\u015fenler \u015funlar olabilir:<\/p>\n Bu bile\u015fenlerin birbirleriyle nas\u0131l etkile\u015fime girdi\u011fini bir ak\u0131\u015f \u015femas\u0131 \u015feklinde g\u00f6rselle\u015ftirmek faydal\u0131 olacakt\u0131r:<\/p>\n <\/code><\/p>\n URL K\u0131saltma Ak\u0131\u015f\u0131:<\/b><\/p>\n URL Y\u00f6nlendirme Ak\u0131\u015f\u0131:<\/b><\/p>\n Bu y\u00fcksek seviye tasar\u0131m, sistemin ana i\u015f ak\u0131\u015f\u0131n\u0131 ve bile\u015fenlerini net bir \u015fekilde ortaya koyar. \u015eimdi, bu bile\u015fenlerin her birinin i\u00e7ine inerek detaylar\u0131 inceleyelim.<\/p>\n Y\u00fcksek seviye tasar\u0131m\u0131m\u0131z\u0131 olu\u015fturduktan sonra, sistemin kritik bile\u015fenlerinin nas\u0131l \u00e7al\u0131\u015faca\u011f\u0131n\u0131 ve kar\u015f\u0131la\u015fabilece\u011fimiz zorluklar\u0131 ele almam\u0131z gerekiyor. Bu k\u0131s\u0131m, m\u00fchendislik becerilerinizi ve problem \u00e7\u00f6zme yetene\u011finizi en \u00e7ok g\u00f6sterece\u011finiz yerdir.<\/p>\n 7 karakterlik Base62 bir kod \u00fcretmek, TinyURL'\u00fcn kalbindeki en \u00f6nemli ve zorlu g\u00f6revlerden biridir. Base62 (a-z, A-Z, 0-9), yakla\u015f\u0131k 62^7 farkl\u0131 benzersiz k\u0131sa URL olu\u015fturma potansiyeli sunar, bu da yakla\u015f\u0131k 3.5 trilyon kombinasyon demektir. Bu say\u0131, mevcut ve gelecekteki gereksinimlerimiz i\u00e7in yeterli g\u00f6r\u00fcnmektedir. Ancak, bu kodlar\u0131 benzersiz ve verimli bir \u015fekilde nas\u0131l \u00fcretece\u011fiz?<\/p>\n <\/code><\/p>\n Zorluk:<\/b> \u00c7ok say\u0131da URL k\u0131salt\u0131ld\u0131\u011f\u0131nda \u00e7arp\u0131\u015fma olas\u0131l\u0131\u011f\u0131 artar ve bu da veritaban\u0131 sorgular\u0131n\u0131 ve dolay\u0131s\u0131yla gecikmeyi art\u0131r\u0131r. E\u011fer sistem \u00e7ok b\u00fcy\u00fcrse, bu yakla\u015f\u0131m bir darbo\u011faz haline gelebilir. Ayr\u0131ca da\u011f\u0131t\u0131k sistemlerde ayn\u0131 anda iki sunucunun ayn\u0131 k\u0131sa kodu \u00fcretme ve kaydetmeye \u00e7al\u0131\u015fma riski de vard\u0131r (race condition). Bunu \u00e7\u00f6zmek i\u00e7in veritaban\u0131nda k\u0131sa URL s\u00fctununa benzersiz bir indeks eklenerek olas\u0131 \u00e7ak\u0131\u015fmalar\u0131n veritaban\u0131 seviyesinde hata vermesi sa\u011flanabilir, bu durumda uygulama hatay\u0131 yakalay\u0131p yeniden deneme yapabilir.<\/p>\n<\/li>\n <\/code><\/p>\n Avantaj:<\/b> \u00c7arp\u0131\u015fma riski yoktur, \u00e7\u00fcnk\u00fc her ID benzersizdir. Ayr\u0131ca s\u0131ral\u0131 ID'ler sayesinde k\u0131sa URL'ler de bir nevi s\u0131ral\u0131 olur, bu da veritaban\u0131 indekslemesi i\u00e7in faydal\u0131 olabilir. Bizim senaryomuzda, y\u00fcksek throughput ve benzersizlik garantisi i\u00e7in, da\u011f\u0131t\u0131k bir ID \u00fcretici servisi (\u00f6rne\u011fin Snowflake benzeri) kullan\u0131p bu ID'yi Base62'ye d\u00f6n\u00fc\u015ft\u00fcrmek en sa\u011flam yakla\u015f\u0131m olacakt\u0131r. Bu, her zaman benzersiz ve s\u0131ral\u0131 olmaya yak\u0131n k\u0131sa kodlar \u00fcretilmesini sa\u011flar ve \u00e7arp\u0131\u015fma riskini ortadan kald\u0131r\u0131r.<\/p>\n Veri depolama karar\u0131, sistemin \u00f6l\u00e7eklenebilirli\u011fi, tutarl\u0131l\u0131\u011f\u0131 ve performans\u0131n\u0131 do\u011frudan etkiler. TinyURL i\u00e7in depolamam\u0131z gereken temel veriler \u015funlard\u0131r:<\/p>\n SQL Veritaban\u0131 (\u00f6rn: PostgreSQL, MySQL):<\/b><\/p>\n Avantajlar\u0131:<\/b> \u0130li\u015fkisel veri modeli bu t\u00fcr basit bir e\u015fle\u015fme i\u00e7in \u00e7ok uygundur. ACID \u00f6zellikleri sayesinde y\u00fcksek veri tutarl\u0131l\u0131\u011f\u0131 sa\u011flar. Dezavantajlar\u0131:<\/b> Yatay \u00f6l\u00e7eklendirme (sharding) daha karma\u015f\u0131kt\u0131r. Y\u00fcksek okuma\/yazma throughput'unda darbo\u011faz ya\u015fayabilir. 100.000 y\u00f6nlendirme\/saniye gibi hedefler i\u00e7in tek bir SQL veritaban\u0131 yeterli olmayabilir, bu durumda sharding ka\u00e7\u0131n\u0131lmaz hale gelir.<\/p>\n NoSQL Veritaban\u0131 (\u00f6rn: Apache Cassandra, DynamoDB, MongoDB):<\/b><\/p>\n Avantajlar\u0131:<\/b> Do\u011fas\u0131 gere\u011fi y\u00fcksek \u00f6l\u00e7eklenebilirlik sunar, yatay olarak kolayca geni\u015fleyebilir. Y\u00fcksek okuma ve yazma hacimlerini kolayca kald\u0131rabilir. Genellikle daha d\u00fc\u015f\u00fck gecikme s\u00fcreleri sunar. Anahtar-de\u011fer (key-value) tabanl\u0131 NoSQL veritabanlar\u0131, Dezavantajlar\u0131:<\/b> ACID garantileri genellikle daha zay\u0131ft\u0131r (eventual consistency daha yayg\u0131nd\u0131r). Kompleks sorgular (join'ler vb.) ya hi\u00e7 desteklenmez ya da performanslar\u0131 d\u00fc\u015f\u00fckt\u00fcr. \u00d6\u011frenme e\u011frisi daha dik olabilir. E\u011fer t\u0131klama analizi gibi detayl\u0131 raporlama gereksinimleri varsa, ayr\u0131 bir analitik depolama \u00e7\u00f6z\u00fcm\u00fcne ihtiya\u00e7 duyulabilir.<\/p>\n Bizim durumumuzda, 100.000 y\u00f6nlendirme\/saniye hedefi g\u00f6z \u00f6n\u00fcne al\u0131nd\u0131\u011f\u0131nda, ana veri deposu olarak Cassandra gibi, anahtar-de\u011fer depolamaya uygun, y\u00fcksek yazma ve okuma throughput'una sahip bir NoSQL veritaban\u0131 tercih edilebilir. K\u0131salt\u0131lan bir URL'nin orijinaline y\u00f6nlendirilmesi, TinyURL benzeri bir servisin en s\u0131k kullan\u0131lan ve dolay\u0131s\u0131yla en kritik performans gereksinimi olan \u00f6zelli\u011fidir. 100.000 y\u00f6nlendirme\/saniye hedefine ula\u015fmak i\u00e7in g\u00fc\u00e7l\u00fc bir \u00f6nbellekleme stratejisi ve da\u011f\u0131t\u0131k bir mimari elzemdir.<\/p>\n \u00d6nbellekleme (Caching):<\/b><\/p>\n En s\u0131k y\u00f6nlendirilen URL'ler i\u00e7in bir \u00f6nbellek katman\u0131 olmazsa olmazd\u0131r. Y\u00f6nlendirme servisi, gelen k\u0131sa kodu \u00f6nce \u00f6nbellekte arar. E\u011fer bulursa, do\u011frudan \u00f6nbellekten y\u00f6nlendirmeyi yapar. Bu, veritaban\u0131 y\u00fck\u00fcn\u00fc b\u00fcy\u00fck \u00f6l\u00e7\u00fcde azalt\u0131r ve gecikmeyi d\u00fc\u015f\u00fcr\u00fcr. Redis veya Memcached, bu t\u00fcr da\u011f\u0131t\u0131k \u00f6nbellekleme i\u00e7in pop\u00fcler se\u00e7eneklerdir.<\/p>\n \u00d6nbellek Stratejisi:<\/b><\/p>\n Da\u011f\u0131t\u0131k Mimari ve Y\u00fck Dengeleme:<\/b><\/p>\n Y\u00f6nlendirme servisinin birden fazla \u00f6rne\u011fini \u00e7al\u0131\u015ft\u0131rmak ve gelen istekleri bu \u00f6rneklere da\u011f\u0131tmak i\u00e7in bir y\u00fck dengeleyici kullanmak zorunludur. Y\u00fck dengeleyiciler, sunucular\u0131n a\u015f\u0131r\u0131 y\u00fcklenmesini \u00f6nler ve hizmet kesintilerini minimize eder. E\u011fer co\u011frafi olarak da\u011f\u0131t\u0131lm\u0131\u015f kullan\u0131c\u0131 taban\u0131na sahipsek, global y\u00fck dengeleyiciler (\u00f6rne\u011fin DNS tabanl\u0131) kullanarak istekleri kullan\u0131c\u0131lara en yak\u0131n veri merkezlerine y\u00f6nlendirebiliriz. Bu, y\u00f6nlendirme gecikmesini daha da azalt\u0131r.<\/p>\n CDN Kullan\u0131m\u0131:<\/b><\/p>\n Normalde URL y\u00f6nlendirmeleri i\u00e7in CDN kullan\u0131lmaz, \u00e7\u00fcnk\u00fc CDN'ler statik i\u00e7erik i\u00e7in daha uygundur. Ancak, e\u011fer k\u0131sa URL'ler i\u00e7in \u00f6zel bir alan ad\u0131m\u0131z varsa ve bu alan ad\u0131n\u0131n DNS \u00e7\u00f6z\u00fcmlemesini h\u0131zland\u0131rmak veya HTTP iste\u011fini co\u011frafi olarak en yak\u0131n sunucuya y\u00f6nlendirmek istersek, CDN'nin baz\u0131 \u00f6zelliklerinden faydalan\u0131labilir. Y\u00f6nlendirme mant\u0131\u011f\u0131 CDN'de de\u011fil, bizim uygulama sunucular\u0131m\u0131zda kalacakt\u0131r.<\/p>\n Performans Optimizasyonlar\u0131:<\/b><\/p>\n Bu detaylar, sistemin sadece \"\u00e7al\u0131\u015fmas\u0131n\u0131\" de\u011fil, ayn\u0131 zamanda belirlenen performans hedeflerine ula\u015fmas\u0131n\u0131 da sa\u011flar.<\/p>\n Bir sistemin temelini att\u0131ktan ve kritik bile\u015fenlerini tasarlad\u0131ktan sonra, daha deneyimli m\u00fchendislerin g\u00f6z \u00f6n\u00fcnde bulundurdu\u011fu ileri d\u00fczey konulara odaklanmak, tasar\u0131m\u0131n\u0131z\u0131n sa\u011flaml\u0131\u011f\u0131n\u0131 ve uzun \u00f6m\u00fcrl\u00fcl\u00fc\u011f\u00fcn\u00fc art\u0131r\u0131r. Bu ipu\u00e7lar\u0131, m\u00fclakatlarda rakiplerinizden s\u0131yr\u0131lman\u0131z\u0131 sa\u011flayacak detaylard\u0131r.<\/p>\n \u00d6nbellekleme, sistem performans\u0131n\u0131n kilit noktalar\u0131ndan biridir, ancak yanl\u0131\u015f kullan\u0131ld\u0131\u011f\u0131nda tutarl\u0131l\u0131k sorunlar\u0131na yol a\u00e7abilir. S\u0131k eri\u015filen verileri \u00f6nbellekte tutmak harikad\u0131r, ancak bu verilerin g\u00fcncelli\u011fini nas\u0131l sa\u011flayaca\u011f\u0131z? TTL (Time-To-Live)<\/b>, \u00f6nbellekteki bir \u00f6\u011fenin ne kadar s\u00fcreyle ge\u00e7erli kalaca\u011f\u0131n\u0131 belirler. TinyURL \u00f6rne\u011finde, bir k\u0131sa URL olu\u015fturuldu\u011funda ve \u00f6nbelle\u011fe al\u0131nd\u0131\u011f\u0131nda, bunun bir TTL'si olmal\u0131d\u0131r. E\u011fer bir URL'nin t\u0131klanma istatistiklerini ger\u00e7ek zamanl\u0131 olarak g\u00fcncellemek istiyorsak, bu, \u00f6nbellekteki t\u0131klama say\u0131s\u0131n\u0131n veritaban\u0131ndaki ile tutarl\u0131 olmas\u0131 gerekti\u011fi anlam\u0131na gelir. Ancak URL y\u00f6nlendirmesi i\u00e7in genellikle orijinal URL de\u011fi\u015fmez, bu y\u00fczden daha uzun bir TTL veya TTL'siz \u00f6nbellekleme tercih edilebilir.<\/p>\n \u00d6nbellek Ge\u00e7ersiz K\u0131lma (Cache Invalidation):<\/b> Bu, da\u011f\u0131t\u0131k sistemlerdeki en zorlu problemlerden biridir. E\u011fer bir orijinal URL'nin hedefini de\u011fi\u015ftirme veya k\u0131sa URL'yi silme gibi bir senaryo olsayd\u0131, \u00f6nbellekteki eski verilerin an\u0131nda ge\u00e7ersiz k\u0131l\u0131nmas\u0131 gerekirdi. Bunun i\u00e7in bir mesaj kuyru\u011fu (\u00f6rne\u011fin Kafka) kullanarak, bir veri de\u011fi\u015fti\u011finde \u00f6nbellekleme servisine bir mesaj g\u00f6nderebilir ve ilgili \u00f6nbellek \u00f6\u011fesini silebiliriz. Ancak TinyURL'de genellikle k\u0131salt\u0131lm\u0131\u015f URL'ler de\u011fi\u015fmez, bu da bu problemi basitle\u015ftirir. Yine de, sistem genelinde tutarl\u0131l\u0131k garantileri i\u00e7in bu mekanizmalar\u0131 bilmek \u00f6nemlidir.<\/p>\n Da\u011f\u0131t\u0131k sistemler do\u011fas\u0131 gere\u011fi hata yapmaya meyillidir. A\u011f kesintileri, sunucu ar\u0131zalar\u0131 veya veri tutars\u0131zl\u0131klar\u0131 her an meydana gelebilir. Bu nedenle, hata y\u00f6netimi ve tutarl\u0131l\u0131k stratejileri b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r.<\/p>\n Bir sistemin \u00fcretim ortam\u0131nda ba\u015far\u0131l\u0131 bir \u015fekilde \u00e7al\u0131\u015fabilmesi i\u00e7in s\u00fcrekli izlenmesi, loglanmas\u0131 ve analitik veriler toplamas\u0131 gerekir. Bu, sorunlar\u0131 proaktif olarak tespit etmenizi, performans darbo\u011fazlar\u0131n\u0131 gidermenizi ve kullan\u0131c\u0131 davran\u0131\u015flar\u0131n\u0131 anlaman\u0131z\u0131 sa\u011flar.<\/p>\n Bu ileri d\u00fczey konular, sadece sistemin \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamakla kalmaz, ayn\u0131 zamanda onun g\u00fcvenilir, performansl\u0131 ve y\u00f6netilebilir olmas\u0131n\u0131 da garanti eder. M\u00fclakatlarda bu konulara de\u011finmek, tasar\u0131ma geni\u015f bir perspektiften yakla\u015ft\u0131\u011f\u0131n\u0131z\u0131 ve ger\u00e7ek d\u00fcnya operasyonel zorluklar\u0131n\u0131n fark\u0131nda oldu\u011funuzu g\u00f6sterir.<\/p>\n Bu makalede, \"5 dakikal\u0131k\" gibi g\u00f6r\u00fcnen ancak derinlemesine m\u00fchendislik bilgisi gerektiren sistem tasar\u0131m sorular\u0131n\u0131n neden pek \u00e7ok m\u00fchendisin zorland\u0131\u011f\u0131 bir alan oldu\u011funu ve TinyURL \u00f6rne\u011fi \u00fczerinden ad\u0131m ad\u0131m nas\u0131l ba\u015far\u0131l\u0131 bir tasar\u0131m yap\u0131labilece\u011fini inceledik. Temel prensiplerden ileri d\u00fczey konulara kadar bir\u00e7ok noktaya de\u011findik. \u00d6zetle, sistem tasar\u0131m\u0131nda ba\u015far\u0131l\u0131 olmak i\u00e7in sadece teknik bilgiye sahip olmak yeterli de\u011fildir; ayn\u0131 zamanda yap\u0131land\u0131r\u0131lm\u0131\u015f bir d\u00fc\u015f\u00fcnce s\u00fcreci, do\u011fru sorular\u0131 sorma yetene\u011fi ve farkl\u0131 mimari kararlar\u0131n takaslar\u0131n\u0131 anlama becerisi de kritik \u00f6neme sahiptir.<\/p>\n Unutmay\u0131n, iyi bir sistem tasar\u0131m\u0131 tek seferde m\u00fckemmel olmaz. S\u00fcrekli iyile\u015ftirme, yeniden de\u011ferlendirme ve de\u011fi\u015fen gereksinimlere uyum sa\u011flama s\u00fcrecidir. M\u00fclakatlarda da benzer bir esnekli\u011fi ve adaptasyonu g\u00f6stermek, m\u00fclakat\u00e7\u0131y\u0131 etkileyecektir. Y\u00fcksek seviye mimariden ba\u015flay\u0131p, kritik bile\u015fenlere derinlemesine inmek ve ard\u0131ndan operasyonel kayg\u0131lar\u0131 (hata y\u00f6netimi, izleme, \u00f6l\u00e7eklenebilirlik) ele almak, sa\u011flam bir tasar\u0131m sunman\u0131n anahtar\u0131d\u0131r. Bu s\u00fcre\u00e7te kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131z her karar\u0131n ard\u0131ndaki mant\u0131\u011f\u0131 ve nedenini a\u00e7\u0131klayabilmeniz, kendinize olan g\u00fcveninizi ve bilginizi yans\u0131tacakt\u0131r.<\/p>\n Ger\u00e7ek d\u00fcnya senaryolar\u0131nda, bu t\u00fcr sistemler genellikle \u00e7ok daha karma\u015f\u0131k hale gelir. \u00d6rne\u011fin, g\u00fcvenlik katmanlar\u0131, \u00e7oklu veri merkezleri, CI\/CD s\u00fcre\u00e7leri, A\/B testleri gibi bir\u00e7ok ek fakt\u00f6r devreye girer. Ancak bir m\u00fclakat ba\u011flam\u0131nda, bu makalede ele ald\u0131\u011f\u0131m\u0131z prensipler ve teknikler, temel bir sistem tasar\u0131m\u0131n\u0131 ba\u015far\u0131yla tamamlaman\u0131z i\u00e7in g\u00fc\u00e7l\u00fc bir temel olu\u015fturacakt\u0131r. Pratik yapmaya devam edin, farkl\u0131 sistem tasar\u0131m sorular\u0131n\u0131 inceleyin ve her zaman \"neden\" sorusunu sormaktan \u00e7ekinmeyin. Bu, sizi sadece daha iyi bir sistem tasar\u0131mc\u0131s\u0131 de\u011fil, ayn\u0131 zamanda daha iyi bir m\u00fchendis yapacakt\u0131r.<\/p>\n S1: Neden k\u0131sa URL'ler i\u00e7in \u00f6zel bir ID \u00fcreticiye ihtiya\u00e7 duyar\u0131z?<\/b><\/p>\n C1: Rastgele k\u0131sa kod \u00fcretimi, \u00f6zellikle y\u00fcksek hacimli sistemlerde \u00e7arp\u0131\u015fma (collision) olas\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r ve bu da veritaban\u0131 kontrolleri nedeniyle performans\u0131 d\u00fc\u015f\u00fcr\u00fcr. Otomatik artan veritaban\u0131 ID'leri da\u011f\u0131t\u0131k sistemlerde benzersizli\u011fi garanti edemez \u00e7\u00fcnk\u00fc farkl\u0131 sunucular veya veritaban\u0131 par\u00e7alar\u0131 ayn\u0131 ID'leri \u00fcretebilir. Da\u011f\u0131t\u0131k bir ID \u00fcretici (\u00f6rne\u011fin Snowflake benzeri bir algoritma) kullanarak hem benzersizli\u011fi garanti ederiz hem de kod olu\u015fturma s\u00fcrecindeki gecikmeyi ve veritaban\u0131 y\u00fck\u00fcn\u00fc azalt\u0131r\u0131z.<\/p>\n S2: Veritaban\u0131 sharding'i (par\u00e7alama) TinyURL'de nas\u0131l uygulanabilir?<\/b><\/p>\n C2: Sharding, veritaban\u0131n\u0131 daha k\u00fc\u00e7\u00fck, y\u00f6netilebilir par\u00e7alara (shard'lara) b\u00f6lerek yatay \u00f6l\u00e7eklendirmeyi sa\u011flar. TinyURL'de S3: \u00d6nbellekleme stratejileri aras\u0131nda ne farklar vard\u0131r?<\/b><\/p>\n C3: Ba\u015fl\u0131ca \u00f6nbellekleme stratejileri Read-Through, Write-Through ve Write-Back'tir. Read-Through'da, veri \u00f6nbellekte yoksa veritaban\u0131ndan okunur ve \u00f6nbelle\u011fe yaz\u0131l\u0131r. Write-Through'da, veri hem veritaban\u0131na hem de \u00f6nbelle\u011fe ayn\u0131 anda yaz\u0131l\u0131r. Write-Back'te ise veri \u00f6nce \u00f6nbelle\u011fe yaz\u0131l\u0131r, ard\u0131ndan asenkron olarak veritaban\u0131na kaydedilir. TinyURL gibi sistemlerde h\u0131zl\u0131 okumalar (y\u00f6nlendirmeler) i\u00e7in Read-Through ve yeni k\u0131saltmalar\u0131n hemen eri\u015filebilir olmas\u0131 i\u00e7in Write-Through stratejileri yayg\u0131n olarak kullan\u0131l\u0131r.<\/p>\n S4: Custom URL'ler (kullan\u0131c\u0131n\u0131n kendi istedi\u011fi k\u0131saltma) nas\u0131l ele al\u0131n\u0131r?<\/b><\/p>\n C4: Custom URL'ler, kullan\u0131c\u0131lar\u0131n istedikleri k\u0131sa kodu belirlemesine olanak tan\u0131r. Bu durumda, kullan\u0131c\u0131 taraf\u0131ndan sa\u011flanan k\u0131sa kodun veritaban\u0131nda daha \u00f6nce kullan\u0131l\u0131p kullan\u0131lmad\u0131\u011f\u0131n\u0131 kontrol etmemiz gerekir. E\u011fer kullan\u0131lm\u0131\u015fsa, kullan\u0131c\u0131ya bir hata mesaj\u0131 d\u00f6n\u00fcl\u00fcr. Bu \u00f6zellik, benzersizlik kontrol\u00fc a\u00e7\u0131s\u0131ndan ek bir y\u00fck getirir ve \u00e7arp\u0131\u015fma riski olu\u015fturabilece\u011fi i\u00e7in dikkatli y\u00f6netilmelidir. Ayr\u0131ca, baz\u0131 \u00f6zel veya ayr\u0131lm\u0131\u015f anahtar kelimelerin (\u00f6rne\u011fin \"admin\", \"login\") custom URL olarak kullan\u0131lmas\u0131 engellenmelidir.<\/p>\n S5: Sistemimizin bir DDoS sald\u0131r\u0131s\u0131na kar\u015f\u0131 dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 nas\u0131l art\u0131rabiliriz?<\/b><\/p>\n C5: DDoS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 korunmak i\u00e7in birden fazla katmanda savunma mekanizmalar\u0131 uygulanabilir:<\/p>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"M\u00fchendislik m\u00fclakatlar\u0131n\u0131n en zorlu a\u015famalar\u0131ndan biri olan sistem tasar\u0131m\u0131 sorular\u0131, \u00e7o\u011fu zaman basit g\u00f6r\u00fcnen ama derinlemesine bilgi ve…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-36248","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n\n
\n
Temel Mimari Bile\u015fenleri ve Rolleri Nelerdir?<\/h3>\n
\n
Uygulamal\u0131 Sistem Tasar\u0131m\u0131: TinyURL \u00d6rne\u011fiyle Ad\u0131m Ad\u0131m<\/h2>\n
Gereksinim Analizi ve Kapsam Belirleme<\/h3>\n
\n
a-z A-Z 0-9<\/code> -> Base62) ve uzunlu\u011fu ne kadar olmal\u0131? (\u00f6rn: 6-8 karakter)<\/li>\n\n
a-zA-Z0-9<\/code>).<\/li>\nY\u00fcksek Seviye Tasar\u0131m: Temel Bile\u015fenleri Birle\u015ftirmek<\/h3>\n
\n
\nKullan\u0131c\u0131\n |\n V\nY\u00fck Dengeleyici (Load Balancer)\n |\n V\nAPI A\u011f Ge\u00e7idi (API Gateway)\n |\n +-----> URL K\u0131saltma Servisi\n | |\n | V\n | K\u0131sa Kod \u00dcretici (ID Generator)\n | |\n | V\n +-----> Veritaban\u0131 (Database)\n | |\n | V\n +-----> \u00d6nbellek (Cache)\n |\n +-----> URL Y\u00f6nlendirme Servisi\n | |\n | V\n +-----> Asenkron Kuyruk (T\u0131klama Analizleri i\u00e7in)\n<\/pre>\n\n
\/shorten<\/code> iste\u011fi g\u00f6nderir.<\/li>\n\n
\/HTTP 301\/302<\/code> y\u00f6nlendirmesi yap\u0131l\u0131r.<\/li>\nDetaylara \u0130nmek: Kritik Bile\u015fenlerin Tasar\u0131m\u0131 ve Zorluklar<\/h2>\n
K\u0131sa URL Olu\u015fturma Mekanizmas\u0131: \u00c7arp\u0131\u015fmalar\u0131 Nas\u0131l \u00d6nleriz?<\/h3>\n
\n
\n function generateShortCode(): string {\n let shortCode = '';\n const chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';\n for (let i = 0; i < 7; i++) {\n shortCode += chars.charAt(Math.floor(Math.random() * chars.length));\n }\n return shortCode;\n }\n\n \/\/ \u00d6rnek kullan\u0131m:\n \/\/ do {\n \/\/ shortUrl = generateShortCode();\n \/\/ } while (database.exists(shortUrl));\n \/\/ database.save(longUrl, shortUrl);\n <\/pre>\n12345<\/code> ise, bunu Base62'ye d\u00f6n\u00fc\u015ft\u00fcrerek B8j<\/code> gibi bir de\u011fer elde edebiliriz. 7 karaktere ula\u015fmak i\u00e7in gerekirse ba\u015f\u0131na s\u0131f\u0131r ekleyebiliriz veya ID'yi daha b\u00fcy\u00fck bir tabana d\u00f6n\u00fc\u015ft\u00fcr\u00fcp daha uzun bir sonu\u00e7 elde edebiliriz.\n\n function encodeToBase62(num: number): string {\n const chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';\n let encoded = '';\n while (num > 0) {\n encoded = chars[num % 62] + encoded;\n num = Math.floor(num \/ 62);\n }\n return encoded || 'a'; \/\/ En k\u00fc\u00e7\u00fck ID (0 veya 1) i\u00e7in 'a' veya 'A'\n }\n\n \/\/ \u00d6rnek kullan\u0131m:\n \/\/ const newId = database.insert(longUrl); \/\/ Veritaban\u0131ndan gelen otomatik ID\n \/\/ const shortUrl = encodeToBase62(newId);\n <\/pre>\n
\n Zorluk:<\/b> Veritaban\u0131 sharding (par\u00e7alama) yap\u0131ld\u0131\u011f\u0131nda otomatik artan ID'ler her shard'da tekrar ba\u015flayabilir ve \u00e7ak\u0131\u015fmalara yol a\u00e7abilir. Bu durumda, da\u011f\u0131t\u0131k ortamda benzersiz ID'ler \u00fcretecek (\u00f6rne\u011fin Twitter Snowflake, UUID'ler veya \u00f6nceden ayr\u0131lm\u0131\u015f ID bloklar\u0131) \u00f6zel bir servis veya algoritma kullanmak gerekir.<\/p>\n<\/li>\n<\/ol>\nVeri Depolama ve Veritaban\u0131 Se\u00e7imi: SQL mi, NoSQL mi?<\/h3>\n
\n
short_code<\/code> (birincil anahtar olarak benzersiz string)<\/li>\noriginal_url<\/code> (uzun string)<\/li>\ncreation_date<\/code><\/li>\nexpiration_date<\/code> (iste\u011fe ba\u011fl\u0131)<\/li>\nuser_id<\/code> (e\u011fer kullan\u0131c\u0131lar login olabiliyorsa)<\/li>\nclick_count<\/code> (analitik i\u00e7in)<\/li>\n<\/ul>\nshort_code<\/code> \u00fczerinde benzersiz indeksleme, \u00e7arp\u0131\u015fmalar\u0131 \u00f6nler. Analitik sorgular (\u00f6rne\u011fin, belirli bir kullan\u0131c\u0131n\u0131n t\u00fcm k\u0131saltmalar\u0131) i\u00e7in g\u00fc\u00e7l\u00fcd\u00fcr.<\/p>\nshort_code<\/code> -> original_url<\/code> e\u015flemesi i\u00e7in idealdir.<\/p>\nshort_code<\/code>'u partition key olarak kullanabiliriz. E\u011fer karma\u015f\u0131k analitik raporlama gereksinimlerimiz olsayd\u0131, bu verileri ayr\u0131 bir veri ambar\u0131na (Data Warehouse) ta\u015f\u0131yabilir ve oradan sorgulayabilirdik.<\/p>\nY\u00f6nlendirme Performans\u0131 ve \u00d6l\u00e7eklenebilirlik<\/h3>\n
\n
\n
\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve Yayg\u0131n Hatalardan Ka\u00e7\u0131nma Yollar\u0131<\/h2>\n
\u00d6nbellekleme ve TTL Stratejileri<\/h3>\n
Da\u011f\u0131t\u0131k Sistemlerde Tutarl\u0131l\u0131k ve Hata Y\u00f6netimi<\/h3>\n
\n
short_code<\/code> ve original_url<\/code> e\u015fle\u015fmesinin strong consistency<\/b> ile depolanmas\u0131 gerekti\u011fini g\u00f6sterir. Ancak t\u0131klama istatistikleri gibi veriler i\u00e7in eventual consistency<\/b> kabul edilebilir; yani bir t\u0131klaman\u0131n say\u0131lmas\u0131n\u0131n birka\u00e7 saniye gecikmesi sorun te\u015fkil etmez. Se\u00e7ti\u011fimiz veritaban\u0131 ve \u00f6nbellek stratejileri bu tutarl\u0131l\u0131k gereksinimlerini kar\u015f\u0131lamal\u0131d\u0131r.<\/li>\nMonitoring, Loglama ve Analitik<\/h3>\n
\n
Sonu\u00e7: Daha \u0130yi Bir Sistem Tasar\u0131mc\u0131s\u0131 Olmak \u0130\u00e7in<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
short_code<\/code>, sharding i\u00e7in iyi bir anahtar (shard key) olabilir. \u00d6rne\u011fin, k\u0131sa kodun ilk birka\u00e7 karakterine g\u00f6re verileri farkl\u0131 shard'lara da\u011f\u0131tabiliriz. Bu, her bir shard'\u0131n daha az veri i\u015flemesini ve dolay\u0131s\u0131yla daha h\u0131zl\u0131 yan\u0131t vermesini sa\u011flar. Ancak, bir shard'daki verilerin dengeli da\u011f\u0131lmas\u0131n\u0131 sa\u011flamak ve shard'lar aras\u0131 sorgular\u0131 (e\u011fer varsa) y\u00f6netmek karma\u015f\u0131k olabilir.<\/p>\n\n