**Bu kaynağın [çeviri](TRANSLATIONS.md)sine yardım edebirsiniz!**
# Sistem Tasarım Rehberi
<palign="center">
<imgsrc="images/jj3A5N8.png">
<br/>
</p>
## Amaç
> Büyük ölçekli sistemler için sistem tasarımını öğrenmek.
>
> Sistem tasarımı mülakatlarına hazırlanmak.
### Büyük sistemlerin nasıl tasarlacağını öğrenin
Ölçeklenebilir sistemlerin nasıl tasarlanacağını öğrenmek, daha iyi bir mühendis olmanıza yardımcı olacaktır.
Sistem tasarımı, çok geniş bir konudur. İnternette sistem tasarım ilkelerine ilişkin sayısız kaynak bulunmaktadır. **
Bu repo, ölçeklenebilir sistemlerin nasıl oluşturulacağını öğrenmenize yardımcı olabilecek düzenli bir kaynak koleksiyonudur.
### Açık kaynak topluluğundan bilgi edinin
Bu, sürekli güncellenen açık kaynak projesinin ilk sürümüdür.
[Katkı](#katkı)da bulunabilirsiniz!
### Sistem tasarımı görüşmelerine hazırlanın
Pek çok teknoloji şirketinde, görüşmeleri kodlamanın yanı sıra sistem tasarımı da **teknik görüşme sürecinde****gerekli bir adımdır**.
**Sistem tasarımıyla ilgili yaygın mülakat sorularını pratik yapın** ve **örnek çözümler** ile yanıtlarınızı karşılaştırın: tartışmalar, kodlar ve diyagramlar.
Mülakata hazırlık için diğer konular:
* [Çalışma rehberi](#Çalışma-rehberi)
* [Sistem tasarımı mülakat sorusu nasıl ele alınır](#sistem-tasarımı-mülakat-sorusu-nasıl-ele-alınır)
* [Sistem tasarımı mülakat soruları ve **çözümleri**](#sistem-tasarımı-mülakat-soruları-ve-çözümleri)
* [Nesne yönelimli tasarım mülakat soruları ve **çözümleri**](#nesne-yönelimli-tasarım-mülakat-soruları-ve-çözümleri)
* [Diğer sistem tasarımı mülakat soruları](#diğer-sistem-tasarımı-mülakat-soruları)
## Anki bilgi kartları
<palign="center">
<imgsrc="images/zdCAkB3.png">
<br/>
</p>
[Anki bilgi kartları](https://apps.ankiweb.net/)nı temel sistem tasarımı kavramlarını ezberlemenize yardımcı olmak için kullanabilirsiniz.
* [Nesneye yönelik tasarım alıştırma kartları](resources/flash_cards/OO%20Design.apkg)
Her zaman ve her yerde kullanılabilir.
### Kod Kaynakları: Etkileşimli Kodlama Yarışmaları
[**Kodlama Mülakatları**](https://github.com/donnemartin/interactive-coding-challenges)na hazırlanmak için kaynak mı arıyorsunuz?
<palign="center">
<imgsrc="images/b4YtAEN.png">
<br/>
</p>
Lütfen ek bilgi kartlarını içeren [**Etkileşimli Kodlama Yarışmaları**](https://github.com/donnemartin/interactive-coding-challenges) reposuna göz atın:
> Avantajlar ve dezavantajlar da dahil olmak üzere çeşitli sistem tasarımı konularının özeti. **Her şeyin bir karşılığı vardır.**. (Ek çeviri notu: Karşılaştırma sonucunda bir şeyden feragat etmek gerektiği vurgulanmaktadır.)
>
> Her bölüm, ek kaynaklara bağlantılar içerir.
<palign="center">
<imgsrc="images/jrUBAF7.png">
<br/>
</p>
* [Sistem tasarımı konuları: buradan başlayın](#sistem-tasarımı-konuları-buradan-başlayın)
* [1. Adım: Ölçeklenebilirlik video dersini inceleyin](#1-adım-ölçeklenebilirlik-video-dersini-inceleyin)
> Mülakat zaman çizelgenize (kısa, orta, uzun) göre önerilen konuları gözden geçirin.
**S: Mülakatlar için buradaki her şeyi bilmem gerekiyor mu? **
**C: Hayır, mülakata hazırlanmak için buradaki her şeyi bilmenize gerek yok. **
Bir mülakatta size ne sorulacağı aşağıdaki faktörlere bağlıdır:
* Tecrübeniz
* Teknik geçmişiniz
* Görüşme yapacağınız pozisyon(lar)
* Görüşme yapacağınız firma(lar)
* Şans
Daha fazla deneyime sahip adayların genellikle sistem tasarımı konusunda daha fazla bilgiye sahip olmaları beklenir. Yazılım mimarlarından veya ekip liderlerden diğer adaylara göre daha fazlasını bilmeleri beklenebilir. En iyi teknoloji şirketleri, genellikle bir veya daha fazla sistem tasarımı mülakatı yapmaktadır.
Geniş bir perspektifle başlayın ve daha derine inmek için birkaç alana odaklanın. Önemli bazı sistem tasarım konuları hakkında biraz bilgi sahibi olmak faydalı olacaktır. Aşağıdaki rehberi, zaman çizelgenize, deneyiminize, hangi pozisyonlar için hangi şirketlerle mülakat yapacağınıza göre ayarlayın.
* **Kısa zaman çizelgesi** - Sistem tasarımı konularında **geniş bir bakış açısı** hedefleyin. **Birkaç** mülakat sorusu çözerek pratiğinizi artırın.
* **Orta zaman çizelgesi** - Sistem tasarımı konularında **geniş bir bakış açısı** ve **biraz derinlik** elde etmeyi hedefleyin. **Birçok** mülakat sorusunu çözerek pratiğinizi artırın.
* **Uzun zaman çizelgesi** - Sistem tasarımı konularında **geniş bir bakış açısı** ve **daha fazla derinlik** elde etmeyi hedefleyin. Mülakat sorularının **çoğu**nu çözerek pratiğinizi artırın.
| [Sistem tasarımı konuları dizini](#sistem-tasarımı-konuları-dizini)ni okuyarak geniş bir fikir edinin | :+1: | :+1: | :+1: |
| Mülakat yapacağınız şirketlerin bazı [mühendislik blog yazılarını](#şirketlerin-mühendislik-blogları) okuyun | :+1: | :+1: | :+1: |
| Bazı [Gerçek dünya mimarileri](#gerçek-dünya-mimarileri) başlıklarını inceleyin | :+1: | :+1: | :+1: |
| [Sistem tasarımı mülakat sorusu nasıl ele alınır](#sistem-tasarımı-mülakat-sorusu-nasıl-ele-alınır) başlığını inceleyin | :+1: | :+1: | :+1: |
| [Sistem tasarımı mülakat soruları ve çözümleri](#sistem-tasarımı-mülakat-soruları-ve-çözümleri)ne çalışın | Birkaç | Birçok | Çoğu |
| [Nesne yönelimli tasarım mülakat soruları ve cevapları](#nesne-yönelimli-tasarım-mülakat-soruları-ve-çözümleri)ne çalışın | Birkaç | Birçok | Çoğu |
| [Diğer sistem tasarımı mülakat soruları](#diğer-sistem-tasarımı-mülakat-soruları)nı gözden geçirin | Birkaç | Birçok | Çoğu |
## Sistem tasarımı mülakat sorusu nasıl ele alınır?
Sistem tasarımı mülakatı**açık uçlu bir görüşmedir**. Konuşmayı sizin yönlendirmeniz beklenir.
Tartışmayı yönlendirmek için aşağıdaki adımları kullanabilirsiniz. Bu süreci sağlamlaştırmak için lütfen aşağıdaki adımları kullanarak [Sistem tasarımı mülakat soruları ve çözümleri](#sistem-tasarımı-mülakat-soruları-ve-çözümleri) bölümüne bakınız.
### Adım 1: Kullanım senaryolarını, kısıtlamaları ve varsayımları açıklayın
İhtiyacınız olan her şeyi bir araya toplayın ve soruna bakın. Kullanım senaryolarını ve kısıtlamaları net bir şekilde anlayabilmek için sorular sormaya devam edin. Varsayımları tartışın.
* Kim kullanacak?
* Nasıl kullanacaklar?
* Kaç kullanıcı var?
* Sistemin işlevi nedir?
* Sistemin girişi ve çıkışı nelerdir?
* Ne kadar veri işlenmek isteniyor?
* Saniyede kaç isteğin işleme alınması bekleniyor?
* İstenilen okuma-yazma oranı nedir?
### Adım 2: Üst düzey bir tasarım oluşturun
Üst düzey bir tasarımın ana hatlarını çizmek için tüm önemli bileşenleri kullanın.
* Ana bileşenleri ve bağlantıları çizin
* Fikrinizi gerekçelendirin
### Adım 3: Temel bileşenleri tasarlayın
Her bir temel bileşenin ayrıntılı ve derinlemesine analizini gerçekleştirin. Örneğin, sizden [URL kısaltma hizmeti tasarlamanız](solutions/system_design/pastebin/README.md) istendiyse, bunları tartışın:
* Tam URL'nin hash değerini oluşturmak ve saklamak
* [MD5](solutions/system_design/pastebin/README.md) ve [Base62](solutions/system_design/pastebin/README.md)
* Hash çakışmaları (Hash collisions)
* SQL veya NoSQL
* Veritabanı modeli
* Hash edilmiş URL'yi tam bir URL'ye çevirmek
* Veritabanı araması
* API ve nesne yönelimli tasarım
### Adım 4: Tasarımı genişletin
Sistemin performansını etkileyen durumları ve sınırlamaları belirleyin ve ele alın. Örneğin, genişletme sorununu(address scalability issue) tanımlamak için aşağıdakilere ihtiyacınız var mı?
* Yük dengeleme (Load balancer)
* Yatay genişleme (Horizontal scaling)
* Önbellek (Caching)
* Veritabanı parçalama (Database sharding)
Olası çözümleri ve maliyetleri tartışın. Her şeyin bir karşılığı vardır. (Ek çeviri notu: Karşılaştırma sonucunda bir şeyden feragat etmek gerektiği vurgulanmaktadır.) [Ölçeklenebilir sistemler için tasarım ilkeleri](#sistem-tasarımı-konuları-dizini)ni kullanarak tasarımdaki performans veya kapasite kısıtlamalarını belirleyin.
### Tahmini hesaplama
Elle bazı tahminler yapmanız istenebilir. [Ek](#ek) olarak aşağıdaki kaynaklara bakabilirsiniz:
* [Use back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)
* [2'nin kuvvet tablosu](#ikinin-kuvveti-tablosu)
* [Her programcının bilmesi gereken gecikme sayıları](#Her-programcının-bilmesi-gereken-gecikme-sayıları)
### Kaynak(lar) ve ek okuma
Daha iyi bir fikir edinmek için aşağıdaki bağlantılara göz atın:
* [How to ace a systems design interview](https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/)
* [The system design interview](http://www.hiredintech.com/system-design)
* [Intro to Architecture and Systems Design Interviews](https://www.youtube.com/watch?v=ZgdS0EUmn70)
Daha sonra, üst düzey karşılaştırmalara bakacağız:
* **Performans** veya **Ölçeklenebilirlik**
* **Gecikme** veya **Verim**
* **Kullanılabilirlik** veya **Tutarlılık**
Her şeyin bir karşılığı olduğunu unutmayın. (Ek çeviri notu: Karşılaştırma sonucunda bir şeyden feragat etmek gerektiği vurgulanmaktadır.)
Daha sonra alan adı sistemi(DNS), içerik dağıtım ağları(CDNs) ve yük dengeleyiciler(load balancers) gibi daha spesifik konuları inceleyeceğiz.
## Performans veya ölçeklenebilirlik
Bir hizmetin **performansı** kaynaklardaki artışla orantılı olarak artıyorsa ölçeklenebilirdir. Performansı artırmak genellikle daha fazla iş birimine hizmet etmek anlamına gelir ancak diğer yandan veri seti büyüdüğünde daha büyük iş birimlerini de işleyebilir. <sup><ahref="http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html">1</a></sup>
Performans veya ölçeklenebilirliğe başka bir bakış açısı:
* Sisteminizde **performans** sorunları varsa, tek bir kullanıcı için yavaş olacaktır.
* Sisteminizde **ölçeklenebilirlik** sorunları varsa, tek kullanıcı için daha hızlı olacaktır ancak yüksek yük altında yavaşlayacaktır.
### Kaynak(lar) ve ek okuma
* [A word on scalability](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
**Gecikme**, bir işlemin veya bir hesaplamanın sonucunun gerçekleştirilmesi için gereken süredir.
**Verim**, birim zamanda gerçekleştirilen bu tür işlemlerin veya işlemlerin sayısıdır.
Genel olarak, kabul edilebilir gecikme süresiyle verimi en üst düzeye çıkarmayı hedeflemelisiniz.
### Kaynak(lar) ve ek okuma
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/fv/posts/understanding-latency-vs-throughput)
## Kullanılabilirlik veya tutarlılık
### CAP Teoremi
<palign="center">
<imgsrc="images/bgLMI2u.png">
<br/>
<i><ahref=http://robertgreiner.com/2014/08/cap-theorem-revisited>Kaynak: CAP theorem revisited</a></i>
</p>
Dağıtılmış bir bilgisayar sisteminde aynı anda yalnızca aşağıdaki iki nokta karşılanabilir:
* **Tutarlılık** ─ Her okuma, en güncel yazıyı veya bir hatayı alır.
* **Ulaşılabilirlik** ─ Her istek bir yanıt alır, ancak bu yanıtın en güncel bilgiyi içerme garantisi yoktur.
* **Bölüm Toleransı** ─ Sistem, ağ hatalarından kaynaklanan keyfi bölünmelere rağmen çalışmaya devam eder.
*Ağlar güvenilir değil, bu nedenle bölüm toleransını desteklemeniz gerekecektir. Tutarlılık ve erişilebilirlik arasında bir yazılım takası yapmanız gerekecektir.*
#### CP ─ Tutarlılık ve Bölüm Toleransı
Bölünmüş bir düğümden yanıt beklemek, bir zaman aşımı hatasına neden olabilir. CP, iş gereksinimleriniz atomik okuma ve yazma gerektiriyorsa iyi bir seçenektir.
#### AP ─ Kullanılabilirlik ve Bölüm Toleransı
Yanıtlar, herhangi bir düğümde bulunan en hızlı mevcut veri sürümünü döndürür, bu her zaman en güncel olmayabilir. Yazılar, bölüm çözüldüğünde yayılmak için bir süre alabilir.
AP, iş gereksinimlerinin [nihai tutarlılığı](#nihai-tutarlılık)na izin vermesi veya sistem dış hatalara rağmen çalışmaya devam etmesi gerekiyorsa iyi bir seçenektir.
* [A plain english introduction to CAP theorem](http://ksat.me/a-plain-english-introduction-to-cap-theorem)
* [CAP FAQ](https://github.com/henryr/cap-faq)
* [The CAP theorem](https://www.youtube.com/watch?v=k-Yaq8AHlFA)
## Tutarlılık modelleri
Aynı verinin birden fazla kopyasıyla, bu verileri nasıl senkronize edeceğimize dair seçeneklerle karşılaşırız, böylece istemciler verilerin tutarlı bir görünümüne sahiptir. [CAP Teoremi](#cap-teoremi)ndeki tutarlılık tanımını hatırlayalım - Her okuma, en güncel yazıyı veya bir hatayı alır.
### Zayıf tutarlılık
Bir yazma işleminden sonra, okumalar bunu görebilir veya görmeyebilir. Burada bir çaba sarf edilir.
Bu yaklaşım, memcached gibi sistemlerde görülür. Zayıf tutarlılık, VoIP, video sohbet ve gerçek zamanlı çok oyunculu oyunlar gibi gerçek zamanlı kullanım durumlarında iyi çalışır. Örneğin, bir telefon görüşmesinde birkaç saniyeliğine bağlantı kaybı yaşarsanız, bağlantıyı tekrar sağladığınızda bağlantı kaybı sırasında söylenenleri duymazsınız.
### Nihai tutarlılık
Bir yazma işleminden sonra, okumalar bunu nihayetinde görecektir (genellikle milisaniyeler içinde). Veri asenkron olarak replike edilir.
Bu yaklaşım, DNS ve e-posta gibi sistemlerde görülür. Nihai tutarlılık, yüksek düzeyde erişilebilir sistemlerde iyi çalışır.
### Güçlü tutarlılık
Bir yazma işleminden sonra, okumalar bunu görecektir. Veri senkron olarak replike edilir.
Bu yaklaşım, dosya sistemleri ve RDBMS gibi sistemlerde görülür. Güçlü tutarlılık, işlemlere ihtiyaç duyan sistemlerde iyi çalışır.
### Kaynak(lar) ve ek okuma
* [Transactions across data centers](http://snarfed.org/transactions_across_datacenters_io.html)
## Kullanılabilirlik modları
Yüksek kullanılabilirliği destekleyen iki mod vardır: yük devretme(fail-over) ve çoğaltma(replication).
### Yük devretme
#### Aktif-pasif
Aktif-pasif yük devretme(fail-over) durumunda, aktif ve pasif durumda bekleyen sunucular arasında kalp atışları(heartbeats) gönderilir. Eğer kalp atışı kesilirse, pasif sunucu aktifin IP adresini devralır ve hizmete devam eder.
Downtime süresi, pasif sunucunun zaten 'sıcak' beklemede çalışıp çalışmadığına veya 'soğuk' beklemeden başlaması gerekip gerekmediğine bağlıdır. Trafik sadece aktif sunucuyu işler.
Aktif-pasif yük devretme(fail-over), aynı zamanda master-slave yük devretme(fail-over) olarak da adlandırılabilir.
#### Aktif-aktif
Aktif-aktif durumunda, her iki sunucu da trafik yönetir ve yükü aralarında paylaşır.
Eğer sunucular genel erişimliyse, DNS her iki sunucunun genel IP'lerini bilmelidir. Eğer sunucular içerideyse, uygulama mantığı her iki sunucuyu bilmelidir.
Aktif-aktif yük devretme(fail-over) aynı zamanda master-master yük devretme(fail-over) olarak da adlandırılabilir.
### Dezavantaj: Yük Devretme
* Fail-over, daha fazla donanım ekler ve ek karmaşıklık getirir..
* Aktif sistem başarısız olmadan önce yeni yazılan veriler pasife replike edilemezse veri kaybı potansiyeli bulunur.
### Çoğaltma
#### Master-slave ve master-master
Bu konu, [veritabanı](#veritabanı) bölümünde daha ayrıntılı olarak incelenmiştir:
Erişilebilirlik genellikle hizmetin kullanılabilir(veya kullanılamaz) olduğu sürenin bir yüzdesi olarak ölçülür. Genellikle erişilebilirlik, 9 sayısıyla ifade edilir - %99.99 erişilebilirliğe sahip bir hizmet, "4 tane 9'a sahip" olarak tanımlanabilir.
#### 99.9% erişilebilirlik - 3 tane 9'a sahip hizmet
Bir hizmet, birden çok hataya duyarlı bileşenden oluşuyorsa, hizmetin genel erişilebilirliği, bileşenlerin sıralı mı yoksa paralel mi olduğuna bağlıdır.
###### Sıralı
Erişilebilirliği %100'den küçük iki bileşenin sıralı olduğu durumda toplam erişilebilirlik düşecektir:
Eğer "Bileşen 1" ve "Bileşen 2" %99.9 erişilebilirliğe sahiplerse toplam erişilebilirlik %99.9999 olacaktır.
## Alan Adı Sistemi (DNS)
<palign="center">
<imgsrc="images/IOyLj4i.jpg">
<br/>
<i><ahref=http://www.slideshare.net/srikrupa5/dns-security-presentation-issa>Kaynak: DNS security presentation</a></i>
</p>
Alan adı sistemi(DNS), www.example.com gibi alan adlarını IP adreslerine dönüştürür.
DNS hiyerarşik bir yapıya sahiptir ve en üst düzeyde birkaç yetkili sunucu bulunur. Modeminiz veya İSS'niz, bir sorgu yaparken hangi DNS sunucusuyla iletişim kurmanız gerektiği konusunda bilgi sağlar. Daha düşük seviyedeki DNS sunucuları eşlemeleri önbelleğe alır ve DNS yayılma gecikmeleri nedeniyle eski hale gelebilir. DNS sonuçları, [Time to Live TTL](https://en.wikipedia.org/wiki/Time_to_live) tarafından belirlenen belirli bir süre boyunca tarayıcınız veya işletim sisteminiz tarafından önbelleğe alınabilir.
* **Ad sunucuları(NS) kaydı (name server)** ─ Alanınız/alt alanınız için DNS sunucularını belirtir.
* **Kayıt (adres)** ─ Belirtilen alan adına karşılık gelen IP adresi kaydı.
* **CNAME (kanonik)** ─ Başka bir alan adı veya "CNAME" kaydıyla (example.com, www.example.com'u işaret eder) veya bir "A" kaydıyla eşleşen bir alan adı.
[CloudFlare](https://www.cloudflare.com/dns/) ve [Route 53](https://aws.amazon.com/route53/) gibi servisler, yönetilen DNS hizmetleri sağlar. Bazı DNS hizmetleri, trafiği çeşitli yöntemlerle yönlendirebilir:
* Bir DNS sunucusuna erişim, yukarıda açıklanan önbellekleme işlemlerinden dolayı hafif bir gecikmeye neden olabilir.
* DNS sunucu yönetimi karmaşık olabilir ve genellikle [hükümetler, İSS'ler ve büyük şirketler](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729) tarafından yönetilir.
* DNS hizmetleri, [DDoS saldırısı](http://dyn.com/blog/dyn-analiz-summary-of-friday-october-21-attack/)na maruz kalabilir, bu da kullanıcıların Twitter gibi web sitelerine erişmesini Twitter'ın IP adres(ler)ini bilmeden engelleyebilir.
<i><ahref=https://www.creative-artworks.eu/why-use-a-content-delivery-network-cdn/>Kaynak: Why use a CDN</a></i>
</p>
İçerik Dağıtım Ağı(CDN), kullanıcılara yakın konumlardan içerik sunan, küresel olarak dağıtılmış bir proxy sunucu ağıdır. Tipik olarak HTML/CSS/JS gibi statik içerikler, resimler ve videolar bir CDN tarafından sunulur, ancak bazı CDNler(örneğin Amazon'un CloudFront dağıtım ağı) dinamik içerik destekler. Sitenin DNS çözümlemesi, istemcilerin hangi sunucuyla iletişim kurması gerektiğini belirtir.
CDN'den içerik sunmak, performansı önemli ölçüde arttırır:
* Kullanıcılar içeriği kendilerine yakın veri merkezlerinden alır.
* Sunucularınız, CDN'nin karşıladığı istekleri karşılamak zorunda kalmaz.
### Push CDN
Push CDN'leri, sunucunuzda değişiklikler olduğunda yeni içerik alır. İçeriği sağlama, doğrudan CDN'ye yükleme ve URL'leri CDN'ye işaret etmek için yeniden yazma konusunda tam sorumluluk alırsınız. İçeriğin ne zaman süresinin dolduğunu ve ne zaman güncellendiğini yapılandırabilirsiniz. İçerik, yeni veya değiştiğinde yalnızca yüklenir, bu da trafiği en aza indirir, ancak depolamayı maksimize eder.
Düşük trafiğe sahip siteler veya içeriği sık güncellenmeyen siteler, push CDN'lerle iyi çalışır. İçerik, düzenli aralıklarla tekrar çekilmek yerine bir kez CDN'lere yerleştirilir.
### Pull CDN
Pull CDN'leri, ilk kullanıcı içeriği istediğinde yeni içeriği sunucunuzdan alır. İçeriği sunucunuzda bırakır ve URL'leri CDN'ye işaret etmek için yeniden yazarsınız. Bu, içerik CDN üzerinde önbelleğe alındığında daha yavaş bir isteğe neden olur.
[Yaşam süresi (TTL)](https://en.wikipedia.org/wiki/Time_to_live), içeriğin ne kadar süreyle önbelleğe alınacağını belirler. Pull CDN'leri, CDN üzerinde depolama alanını en aza indirir, ancak dosyaların süresi dolarsa ve gerçekte değiştirilmeden çekilirse gereksiz trafiğe neden olabilir.
Yüksek trafikli siteler, trafiği daha düzenli bir şekilde dağıttığı için pull CDN'lerle iyi çalışır. CDN'de yalnızca son zamanlarda istenen içerik kalır.
### Dezavantaj(lar): CDN
* CDN maliyetleri, trafiğe bağlı olarak önemli olabilir, ancak bu, CDN kullanmamanız durumunda karşılaşacağınız ek maliyetlerle karşılaştırılmalıdır.
* İçerik, TTL süresi dolmadan önce güncellenirse eski kalabilir.
* CDN'ler, statik içeriğin URL'lerini CDN'ye işaret etmek için değiştirmeyi gerektirir.
<i><ahref=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Kaynak: Scalable system design patterns</a></i>
</p>
Yük dengeleyicileri, gelen istemci isteklerini uygulama sunucuları ve veritabanları gibi bilgi işlem kaynaklarına dağıtır. Her durumda, yük dengeleyici, bilgi işlem kaynağından gelen yanıtı uygun istemciye döndürür. Yük dengeleyicileri şu konularda etkilidir:
* İsteklerin hatalı sunuculara girmesini önlemek
* Kaynak aşırı yüklenmesini önlemek
* Tek hata noktalarını ortadan kaldırmaya yardımcı olmak
Yük dengeleyicileri, donanım (pahalı) veya HAProxy gibi yazılım ile uygulanabilir.
Ek avantajlar şunları içerir:
* **SSL Sonlandırma** ─ Gelen isteklerin şifresini çözer ve sunucu yanıtlarını şifreler, böylece arka uç sunucusunun(back-end) artık bu potansiyel olarak pahalı işlemleri gerçekleştirmesi gerekmez.
* Her sunucuya [X.509 sertifikasını](https://en.wikipedia.org/wiki/X.509) yüklemek gerekmez.
* **Oturum Tutma** ─ Web uygulaması oturumları izlemiyorsa, bir çerez yayınlar ve belirli istemci isteklerini aynı örneğe yönlendirir.
Hataları önlemek için [aktif-pasif](#aktif-pasif) veya [aktif-aktif](#aktif-aktif) modunda birden fazla yük dengeleyicinin kurulması yaygındır.
Yük dengeleyiciler trafiği çeşitli şekillerde yönlendirebilir:
* Rastgele (Random)
* En düşük yüklü (Least loaded)
* Oturum/çerez (Session/cookies)
* [Round robin or ağırlıklı round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)
* [Katman 4](#katman-4-yük-dengeleyicisi)
* [Katman 7](#katman-7-yük-dengeleyicisi)
### Katman 4 yük dengeleyicisi
Katman 4 yük dengeliyicileri, istekleri nasıl dağıtacaklarına karar vermek için [iletişim katmanındaki](#iletişim) bilgilere bakarlar. Genellikle, bu başlıkta bulunan kaynak, hedef IP adresleri ve portları içerir, ancak paketin içeriğini içermez. 4. Katman yük dengeleyicileri, ağ paketlerini yukarı akış sunucuya ve ondan yönlendirirken [Ağ Adresi Çevirisi (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/) işlemini gerçekleştirirler.
### Katman 7 yük dengeleyicisi
Katman 7 yük dengeleyicileri, [uygulama katmanına](#iletişim) bakarak istekleri nasıl dağıtacaklarına karar verirler. Bu, başlık, mesaj ve çerez içeriğini içerebilir. Katman 7 yük dengeleyicileri, ağ trafiğini sonlandırır, mesajı okur, bir yük dengeleme kararı alır ve ardından seçilen sunucuya bir bağlantı açar. Örneğin, Katman 7 yük dengeleyici, video trafiğini videoları barındıran sunuculara yönlendirirken, daha hassas kullanıcı fatura trafiğini güvenlik açısından güçlendirilmiş sunuculara yönlendirebilir.
Esneklik maliyetine karşılık olarak, Katman 4 yük dengeleme, 7. Katmana göre daha az zaman ve hesaplama kaynağı gerektirir, ancak performans etkisi modern ticari donanımlarda minimal olabilir.
### Yatay ölçekleme
Yük dengeleyicileri, yatay ölçeklendirmeye de yardımcı olabilir, performansı ve erişilebilirliği artırabilir. Ticari makineler kullanarak ölçeklendirmek, daha pahalı donanımda tek bir sunucuyu ölçeklendirmekten daha uygun maliyet ve daha yüksek erişilebilirlik sağlar; bu duruma **dikey olarak ölçeklendirme** denir. Ayrıca, ticari donanımda çalışan yetenekleri bulmak, özel kurumsal sistemlerde çalışan yetenekleri bulmaktan daha kolaydır.
#### Dezavantaj(lar): yatay ölçekleme
* Yatay ölçeklendirme karmaşıklığa neden olur ve sunucunun çoğaltılmasını gerektirir.
* Sunucular durum bilgisiz olmalıdır: Ayrıca oturum veya profil resimleri gibi kullanıcıyla ilgili veriler içermemelidir.
* Oturumlar merkezi olarak veritabanında veya kalıcı [önbellek](#önbellek) (Redis, Memcached) veri depolama alanında saklanabilir.
* Önbellekler ve veritabanları gibi aşağı akış(downstream) sunucularının, daha fazla eş zamanlı bağlantıyı yönetebilmek için yukarı akış(upstream) sunucularıyla ölçeklendirilmesi gerekir.
### Dezavantaj(lar): Yük Dengeleyici
* Yeterli kaynak yapılandırılmazsa veya yanlış yapılandırılırsa yük dengeleyici performans darboğazı haline gelebilir.
* Tek hata noktalarını ortadan kaldırmaya yardımcı olmak için yük dengeleyiciler tanıtıldı ancak ek karmaşıklığa yol açtı.
* Tek bir yük dengeleyici tek bir hata noktası oluşturur ancak birden fazla yük dengeleyiciyi yapılandırmak daha fazla karmaşıklık katar.
Ters proxy, dahili hizmetleri merkezi olarak arayabilen ve genel istemcilere birleşik bir arayüz sağlayabilen bir web sunucusudur. İstemciden gelen istek, önce ters proxy sunucusu tarafından isteğe yanıt verebilecek sunucuya iletilir ve ardından proxy, sunucunun yanıt sonucunu istemciye döndürür.
Faydaları şunları içerir:
* **Artırılmış güvenlik** - Arka uç(backend) sunucu bilgilerini gizler, kara listedeki IP'leri engeller ve istemci başına bağlantı sayısını sınırlar.
* **Geliştirilmiş ölçeklenebilirlik ve esneklik** - İstemciler yalnızca ters proxy sunucusunun IP'sini görebilir, bu da sunucuları eklemenize veya kaldırmanıza veya yapılandırmalarını değiştirmenize olanak tanır.
* **SSL Oturumlarının Yerel Sonlandırılması** - Gelen isteklerin şifresini çözer ve sunucu yanıtlarını şifreler, böylece arka uç(backend) sunucusunun maliyetli olabilecek işlemleri tamamlamasına gerek kalmaz.
- Her sunucuya bir [X.509](https://en.wikipedia.org/wiki/X.509) sertifikası yükleme ihtiyacını ortadan kaldırır.
* **SIKIŞTIRMA** - Sunucu yanıtını sıkıştır.
* **Önbellek** - Doğrudan isabet önbellek sonucunu döndürür.
* **Statik İçerik** - Statik içeriği doğrudan yayınlar.
* HTML/CSS/JS
* Resimler
* Videolar
* vs
### Yük dengeleyici ve ters proxy
* Birden fazla sunucunuz olduğunda yük dengeleyici dağıtmak kullanışlıdır. Tipik olarak bir yük dengeleyici, trafiği aynı işlevselliğe sahip bir dizi sunucuya yönlendirir.
* Yalnızca bir web sunucusu veya uygulama sunucusu olduğunda bile ters proxy faydalıdır.Bir önceki bölümde tanıtılan avantajlara bakabilirsiniz.
* NGINX ve HAProxy gibi çözümler hem Katman 7 ters proxy'yi hem de yük dengelemeyi destekleyebilir.
### Dezavantaj(lar): Ters proxy
* Ters proxy'nin eklenmesi sistemin karmaşıklığını artıracaktır.
* Tek bir ters proxy sunucusu yine de tek bir hata noktası olabilir ve birden fazla ters proxy sunucusunun ([yük devretme(failover)](https://en.wikipedia.org/wiki/Failover) gibi) yapılandırılması karmaşıklığı daha da artıracaktır.
### Kaynak(lar) ve ek okuma
* [Reverse proxy vs load balancer](https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/)
<i><ahref=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Kaynak: Intro to architecting systems for scale</a></i>
</p>
Web hizmetleri katmanının uygulama katmanından (platform katmanı olarak da bilinir) ayırmak, her iki katmanı bağımsız olarak ölçeklendirmenize ve yapılandırmanıza olanak tanır. Yeni bir API eklemek, genellikle ek web sunucuları eklemeye gerek olmadan uygulama sunucularını eklemek anlamına gelir.
**Tek Sorumluluk İlkesi**, birbirleriyle birlikte çalışan küçük ve otonom hizmetleri savunur. Küçük ekipler, küçük hizmetlerle hızlı büyüme için daha agresif planlama yapabilirler.
Uygulama katmanındaki iş süreçleri aynı zamanda [asenkronizm](#asenkronizm)i mümkün kılar.
### Mikroservisler
Bu tartışma ile ilgili olan [mikroservisler](https://en.wikipedia.org/wiki/Microservices), bağımsız bir şekilde dağıtılabilen, küçük, modüler hizmetlerin bir paketidir. Her servis, bir iş hedefini karşılamak için iyi tanımlanmış, hafif bir mekanizma aracılığıyla iletişim kuran benzersiz bir süreç çalıştırır. <sup><ahref=https://smartbear.com/learn/api-design/what-are-microservices>1</a></sup>
Örneğin, Pinterest aşağıdaki mikroservislere sahip olabilir: kullanıcı profili, takipçi, haber akışı, arama, fotoğraf yükleme, vb.
### Servis keşfi
[Consul](https://www.consul.io/docs/index.html), [Etcd](https://coreos.com/etcd/docs/latest) ve [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) gibi sistemler, hizmetlerin kayıtlı isimlerini, adreslerini ve bağlantı noktalarını takip ederek birbirlerini bulmalarına yardımcı olabilir. [Sağlık kontrolü](https://www.consul.io/intro/getting-started/checks.html), hizmet bütünlüğünü doğrulamaya yardımcı olur ve genellikle bir [HTTP](#köprü-metni-aktarım-protokolü-http) uç noktası kullanılarak gerçekleştirilir. Hem Consul hem de Etcd, konfigürasyon değerleri ve diğer paylaşılan verileri depolamak için kullanışlı olabilen bir [anahtar-değer deposu](#anahtar-değer-deposu)na sahiptir.
### Dezavantaj(lar): Uygulama katmanı
* Gevşek bağlı hizmetlerle bir uygulama katmanı eklemek, mimari, işletme ve süreç açısından (monolitik bir sistemle karşılaştırıldığında) farklı bir yaklaşım gerektirir.
* Mikroservisler, dağıtımlar ve operasyonlar açısından karmaşıklığı arttırabilir.
### Kaynaklar ve ek okuma
* [Intro to architecting systems for scale](http://lethain.com/introduction-to-architecting-systems-for-scale)
* [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
* **Dayanıklılık (Durability)** - Bir işlem gerçekleştirildikten sonra sistem üzerindeki etkisi kalıcı olur.
İlişkisel bir veritabanını ölçeklendirmek için birçok teknik vardır: **master-slave çoğaltma**, **master-master çoğaltma**, **federasyon**, **parçalama**, **denormalizasyon** ve **SQL Tuning**.
#### Master-slave çoğaltma
Master sunucu, okuma ve yazma hizmeti sunar, yazma işlemlerini bir veya daha fazla slave sunucalara replike eder ve slave sunucular yalnızca okuma işlemleri sunar. Slave sunucular aynı zamanda daha fazla slave sunucuya ağaç benzeri bir şekilde replike edebilir. Master sunucu çevrimdışıysa; bir slave sunucu, ana bilgisayar olarak atanana veya yeni bir master sunucu tahsis edilene kadar; sistem okuma modunda çalışmaya devam edebilir.
* Bir slave sunucuyu, master sunucuya yükseltmek ek bir iş gerektirir.
* Master-slave çoğaltma ve master-master çoğaltma ile ilgili bilgiler için [Dezavantaj(lar): çoğaltma] (#dezavantajlar-çoğaltma) bölümüne bakınız.
#### Master-master çoğaltma
Her iki ana sunucu da okuma ve yazma işlemlerinden sorumludur ve yazma işlemleri sırasında birbirleriyle koordineli çalışırlar. Ana sunuculardan biri kapanırsa sistem okumaya ve yazmaya devam edebilir.
* Hangi veritabanına yazacağınızı belirlemek için yük dengeleyiciye(load balancer) veya uygulama mantığınızda değişiklik yapmanız gerekecektir.
* Çoğu master-master sistem ya tutarlılığı garanti edemez (ACID'i ihlal eder) veya senkronizasyon nedeniyle artan yazma gecikmesine sahiptir.
* Yazma düğümleri(write nodes) ekledikçe ve gecikme arttıkça çatışma çözümü daha fazla devreye girer.
* Master-slave çoğaltma ve master-master çoğaltma ile ilgili bilgiler için [Dezavantaj(lar): çoğaltma] (#dezavantajlar-çoğaltma) bölümüne bakınız.
##### Dezavantaj(lar): çoğaltma
* Yeni yazılan verileri diğer düğümlere kopyalanamadan önce master sunucu kapanırsa veri kaybı olasılığı vardır.
* Yazma işlemleri, okuma işleminden sorumlu kopyaya yeniden dağıtılır. Aşırı yazma işlemleri nedeniyle slave sunucular etkilenebilir ve bu da okuma işlemlerine engel olabilir.
* Ne kadar çok slave sunucu var ise o kadar çoğaltma işlemi yapılması gerekir, bu da ciddi gecikme sorunlarına sebep verecektir.
* Bazı veritabanı sistemlerinde master sunucuya yazma işlemi birden fazla iş parçacığı kullanılarak paralel olarak yazılabilir ancak slave sunucu yalnızca tek iş parçacıklı sıralı yazmayı destekler.
* Çoğaltma, daha fazla donanım ve ek karmaşıklık anlamına gelir.
<strong><ahref="https://www.youtube.com/watch?v=w95murBkYmU">Kaynak: Kullanıcılarınızı İlk On Milyona Kadar Ölçeklendirme</a></strong>
</p>
Federasyon (veya fonksiyonel bölümleme), veritabanını ilgili işlevlere göre böler. Örneğin, tek bir veritabanı yerine üç veritabanınız olabilir: **forumlar**, **kullanıcılar** ve **ürünler**; böylece veritabanı başına okuma ve yazma trafiğini ve çoğaltma gecikmesini azaltırsınız. Daha küçük bir veritabanı, belleğe sığan daha fazla veri anlamına gelir; bu da daha yüksek önbellek isabeti şansı anlamına gelir. Sadece seri olarak yazabilen merkezi bir master sunucu yoktur, yük kapasitesini arttırmak için paralel olarak yazabilirsiniz.
##### Dezavantaj(lar): federasyon
* Veritabanı şemanız çok sayıda işlev ve veri tablosu gerektiriyorsa, federasyon iyi değildir.
* Hangi veritabanından okunacağını ve hangi veritabanına yazılacağını belirlemek için uygulamanızın mantığını güncellemeniz gerekir.
* İki veritabanından gelen veri güncellemelerini birleştirmek [sunucu bağlantısı](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers) ile daha karmaşıktır.
* Federasyon daha fazla donanım ve ek karmaşıklık gerektirir.
##### Kaynak(lar) ve ek okuma: federasyon
* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs)
Parçalama, veriyi farklı veritabanları arasında dağıtan bir yöntemdir, böylece her bir veritabanı yalnızca verinin bir alt kümesini yönetebilir. Kullanıcı veritabanını örnek olarak alalım, kullanıcı sayısı arttıkça kümelere daha fazla parça(shard) eklenir.
[Federasyon](#federasyon)un avantajlarına benzer şekilde, parçalama daha az okuma ve yazma trafiği, daha az çoğaltma ve daha fazla önbellek isabeti sağlar. Ayrıca, genellikle sorguları hızlandırarak performansı artırır. Bir parça(shard) devre dışı kalırsa, diğer parçalar(shard) hala işlevseldir, ancak veri kaybını önlemek için bir tür çoğaltma eklemek isteyebilirsiniz. Federasyon gibi, yazıları seri hale getiren tek bir merkezi ana yoktur, bu da artan bir işlem hızıyla paralel olarak yazma imkanı sağlar.
Kullanıcı tablosunu parçalamak için yaygın yöntemler, kullanıcının soyadının baş harfi veya kullanıcının coğrafi konumu gibi faktörlere dayanmaktadır.
##### Dezavantaj(lar): parçalama
* Parçalamayı uygulamak için uygulama mantığını değiştirmeniz gerekebilir, bu da karmaşık SQL sorgularına yol açabilir.
* Makul olmayan parçalama, dengesiz veri yüküne yol açabilir. Örneğin sık erişilen kullanıcı verileri, kendi parçasının yükünün diğer parçalara göre daha fazla olmasına neden olacaktır.
* Yeniden dengeleme, ek karmaşıklık getirir. [Tutarlı hashing(Consistent hashing)](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html)'e dayalı parçalama işlemleri, transfer edilen veri miktarını azaltabilir.
* Birden fazla parçadan veri birleştirmek daha karmaşıktır.
* Parçalama daha fazla donanım ve ek karmaşıklık gerektirir.
#### Kaynak(lar) ve ek okuma: parçalama
* [The coming of the shard](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html)
Denormalizasyon, bazı yazma performansı kaybı karşılığında okuma performansını artırmaya çalışır. Pahalı birleştirme işlemlerini önlemek için; veriler, birden fazla tabloya yazılır. [PostgreSQL](https://en.wikipedia.org/wiki/PostgreSQL) ve Oracle gibi bazı ilişkisel veritabanları, gereksiz bilgileri depolamanın ve gereksiz kopyaları tutmanın işini yapan [materyalleştirilmiş görünümleri](https://en.wikipedia.org/wiki/Materialized_view) destekler.
Veriler, [federasyon](#federasyon) ve [parçalama](#parçalama) gibi teknikler kullanılarak dağıtıldığında, veri merkezleri arasında birleştirmeleri yönetmek karmaşıklığı daha da artırır. Denormalizasyon, bu tür karmaşık birleştirmeler için ihtiyacı ortadan kaldırabilir.
Çoğu sistemde, okuma işlemlerinin sıklığı, 100:1 ve hatta 1000:1 oranında, yazma işlemlerinden çok daha yüksektir. Karmaşık veritabanı birleştirmeleri gerektiren okuma işlemleri çok maliyetlidir ve disk işlemlerinde çok fazla zaman harcar.
##### Dezavantaj(lar): Denormalizasyon
* Tekrar eden(yinelenen) veri.
* Kısıtlamalar, bilgilerin gereksiz kopyalarının senkronize olmasına yardımcı olabilir, bu da veritabanı tasarımının karmaşıklığını artırır.
* Yoğun yazma yükü altındaki bir denormalize veritabanı, normalleştirilmiş karşıtına göre daha kötü performans gösterebilir.
SQL ayarlama geniş kapsamlı bir konudur ve bu konuyla ilgili pek çok [kitap](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning) yazılmıştır.
Sistem darboğazlarını(bottleneck) simüle etmek ve ortaya çıkarmak için **benchmark** ve **profile**'dan yararlanmak önemlidir.
* **Benchmark** - [ab](http://httpd.apache.org/docs/2.2/programs/ab.html) gibi araçları kullanarak yüksek yük durumlarını simüle eder.
* **Profile** - [Yavaş sorgu log(Slow query log)](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) gibi araçları etkinleştirerek performans sorunlarının izlenmesine yardımcı olur.
Performans analizi(benchmarking) ve profilleme(profiling), aşağıdaki optimizasyonlara yönlendirebilir.
##### Şemayı sınırlandırın
* Hızlı erişim için MySQL, verileri diskteki bitişik bloklarda saklar.
* Sabit uzunluklu alanlar için `VARCHAR` yerine `CHAR` türünü kullanın.
* 'CHAR' hızlı, rastgele erişim için etkilidir. Eğer `VARCHAR` kullanıyorsanız, bir sonraki stringi okumak istiyorsanız öncelikle mevcut stringin sonuna kadar okumanız gerekir.
* Blog metni gibi büyük metin bloklarını depolamak için `TEXT` kullanın. `TEXT` ayrıca boolean aramalarına da izin verir. `TEXT` alanının kullanılması, diskte metin bloğunun yerini belirleyen bir işaretçinin saklanmasını gerektirir.
* 2^32 veya 4 milyara kadar daha büyük sayıları depolamak için `INT` kullanın.
* Para birimlerini saklamak için `DECIMAL` tipini kullanmak, kayan nokta gösterim hatalarını önler.
* Büyük `BLOBS`'leri depolamaktan kaçının, bunun yerine nesnenin alınabileceği konumu depolayın.
*`VARCHAR(255)`, bazı RDBMS'lerde bir baytın kullanımını maksimuma çıkaran bir 8 bit sayısında sayılabilecek en büyük karakter sayısıdır.
* [Arama performansını iyileştirmek](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performans-in-a-database-search) için geçerli senaryolarda `NOT NULL` kısıtlamalarını ayarlayın.
##### Doğru dizini kullanın
* Sorgulanan sütunlar ("SELECT", "GROUP BY", "ORDER BY", "JOIN") bir indekleme kullanıyorsa daha hızlı olacaktır.
* İndeksler genellikle veriyi sıralı tutan ve logaritmik zamanda aramalara, ardışık erişime, ekleme ve silmeye olanak tanıyan öz-dengeli [B-ağacı](https://en.wikipedia.org/wiki/B-tree) olarak temsil edilir.
* Bir indeks yerleştirmek, veriyi bellekte tutabilir ve daha fazla alan gerektirebilir.
* İndekslerin güncellenmesi gerektiğinden yazma işlemleri daha yavaş olabilir.
* Büyük miktarda veri yüklenirken indeksleri devre dışı bırakmak, verileri yüklemek ve ardından indeksleri yeniden oluşturmak daha hızlı olabilir.
##### Pahalı birleştirme işlemlerinden kaçının
* Performans gerekiyorsa [denormalizasyon](#denormalizasyon) yapılabilir.
##### Veri tablosunu bölün
* Tabloyu parçalayarak sıcak noktaları ayrı bir tabloya yerleştirmek, veriyi bellekte tutmaya yardımcı olabilir.
##### Sorgu önbelleğini ayarlayın
* Bazı durumlarda; [sorgu önbelleği](http://dev.mysql.com/doc/refman/5.7/en/query-cache), [performans sorunlarına](https://www.percona.com/blog/2016/10/12/mysql-5-7-performance-tuning-immediately-after-installation/) neden olabilir.
##### Kaynak(lar) ve ek okuma
* [Tips for optimizing MySQL queries](http://aiddroid.com/10-tips-optimizing-mysql-queries-dont-suck/)
* [Is there a good reason i see VARCHAR(255) used so often?](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l)
* [How do null values affect performance?](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)
NoSQL, **anahtar-değer deposu**, **belge deposu**, **geniş sütun deposu** veya **grafik veritabanı** içinde temsil edilen veri öğelerinin bir koleksiyonudur. Veri denormalize edilmiş ve genellikle birleştirmeler uygulama kodu içinde yapılır. Çoğu NoSQL deposu gerçek ACID işlemlerine sahip değildir ve sonunda [nihai tutarlılık](#nihai-tutarlılık) lehine olur.
**BASE**, genellikle NoSQL veritabanlarının özelliklerini tanımlamak için kullanılır. [CAP teoremi](#cap-teoremi) ile karşılaştırıldığında BASE, tutarlılıktan ziyade kullanılabilirliği vurgular.
* **Temel Olarak Kullanılabilir** - sistem, kullanılabilirliği garanti eder.
* **Yumuşak durum** - sistem durumu, giriş yapılmasa bile zaman içinde değişebilir.
* **Nihai tutarlılık** - sistem, belirli bir süre içinde giriş almadığı takdirde zamanla tutarlı hale gelir.
[SQL veya NoSQL](#sql-veya-nosql) arasında seçim yapmanın yanı sıra, NoSQL veritabanı türlerinden hangisinin kullanım durumlarınıza en iyi uyduğunu anlamak da faydalıdır. Sonraki bölümde **anahtar-değer depoları**, **belge depoları**, **geniş sütun depoları** ve **grafik veritabanları**nı gözden geçireceğiz.
#### Anahtar-değer deposu
> Soyutlama: Hash tablosu
Anahtar/değer deposu, genellikle O(1) okuma ve yazma işlemlerine izin verir ve genellikle bellek veya SSD tarafından desteklenir. Veri deposu, anahtarları [sözlük sırasına göre](https://en.wikipedia.org/wiki/Lexicographical_order) tutabilir ve bu da anahtar aralıklarının verimli bir şekilde alınmasına olanak tanır. Anahtar-değer depoları, bir değerle ilişkilendirilmiş meta verilerin depolanmasına izin verebilir.
Anahtar-değer depoları yüksek performans sağlar ve genellikle basit veri modelleri veya hızla değişen veriler için kullanılır, örneğin bellekte tutulan önbellek katmanı. Yalnızca sınırlı bir işlem kümesi sundukları için, ek işlemler gerekiyorsa karmaşıklık uygulama katmanına kaydırılır.
Anahtar-değer deposu, belge deposu gibi daha karmaşık sistemlerin temelini oluşturur ve bazı durumlarda grafik veritabanı olarak da kullanılabilir.
* [Disadvantages of key-value stores](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
> Soyutlama: değerler olarak depolanan belgelerle anahtar-değer deposu
Bir belge deposu, belgeler (XML, JSON, ikili, vb.) etrafında odaklanmıştır, bir belge bir nesne için tüm bilgileri depolar. Belge depolar, belgenin kendi iç yapısına dayalı sorgular yapmak için API'lar veya bir sorgu dilini sağlar. *Not, birçok anahtar-değer deposu, bir değerin meta verileriyle çalışma özellikleri içerir, bu da bu iki depolama türü arasındaki çizgileri bulanıklaştırabilir.*
Kullanılan uygulamaya bağlı olarak belgeler, koleksiyonlar, etiketler, meta veriler veya dizinler tarafından düzenlenir. Belirli bir araya getirilebilecek veya gruplandırılabilecek olsa da belgeler, birbirinden tamamen farklı alanlara sahip olabilir.
[MongoDB](https://www.mongodb.com/mongodb-architecture) ve [CouchDB](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/) gibi bazı belge depoları ayrıca karmaşık sorguları gerçekleştirmek için bir SQL benzeri dil sağlar. [DynamoDB](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf), hem anahtar-değerleri hem de belgeleri destekler.
Belge depoları yüksek esneklik sağlar ve genellikle zaman zaman değişen verilerle çalışmak için kullanılır.
<i><ahref=http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html>Kaynak: SQL & NoSQL, a brief history</a></i>
</p>
> Soyutlama: İç içe geçmiş harita(nested map) `ColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>>`
Geniş sütun depolama biriminin temel veri birimi bir sütundur (ad/değer çifti). Bir sütun, sütun ailelerine (SQL tablosuna benzer) gruplanabilir. Süper sütun aileleri, sütun ailelerini daha da gruplar. Her sütuna bir satır anahtarıyla bağımsız olarak erişebilirsiniz ve aynı satır anahtarına sahip sütunlar bir satır oluşturur. Her değer, sürümleme ve çakışma çözümü için bir zaman damgası içerir.
Google, [Bigtable'ı](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) ilk geniş sütun depolama olarak tanıttı, bu da Hadoop ekosisteminde sıkça kullanılan açık kaynaklı [HBase](https://www.mapr.com/blog/in-third-look-hbase-architecture) ve Facebook tarafından geliştirilen [Cassandra](http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archIntro.html) üzerinde etkili oldu. BigTable, HBase ve Cassandra gibi depolama sistemleri anahtarları leksikografik(alfabetik) sırayla tutar, bu da seçici anahtar aralıklarının etkili bir şekilde alınmasına olanak tanır.
Geniş sütun depolamaları yüksek kullanılabilirlik ve ölçeklenebilirlik sunar. Genellikle çok büyük veri setleri için kullanılırlar.
##### Kaynak(lar) ve ek okuma: geniş sütun depolama
* [SQL & NoSQL, a brief history](http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html)
Grafik veritabanlarında, her düğüm bir kayıtı temsil eder ve her yay bir düğüm arasındaki ilişkiyi ifade eder. Grafik veritabanları, birçok yabancı anahtar veya çoktan çoklu ilişkiyi temsil etmek için optimize edilmiştir.
Grafik veritabanları, sosyal ağ gibi karmaşık ilişkilere sahip veri modelleri için yüksek performans sunar. Nispeten yeni bir teknoloji olmalarına rağmen, henüz geniş çapta kullanılmamaktadırlar; bu nedenle geliştirme araçları ve kaynakları bulmak daha zor olabilir. Birçok grafik veritabanına yalnızca REST API'leri aracılığıyla erişilebilir.
* [Explanation of base terminology](http://stackoverflow.com/questions/3342497/explanation-of-base-terminology)
* [NoSQL databases a survey and decision guidance](https://medium.com/baqend-blog/nosql-databases-a-survey-and-decision-guidance-ea7823a822d#.wskogqenq)
<i><ahref=https://www.infoq.com/articles/Transition-RDBMS-NoSQL/>Kaynak: Transitioning from RDBMS to NoSQL</a></i>
</p>
**SQL**'i seçme nedenleri:
* Yapılandırılmış veri
* Katı şema
* İlişkisel veri
* Karmaşık birleştirmelere ihtiyaç
* İşlemler
* Ölçeklendirme için açık kalıplar
* Mevcut kaynaklar daha zengindir: geliştiriciler, topluluklar, kod kitaplıkları, araçlar vb.
* İndeksleme ile aramalar çok hızlıdır
**NoSQL**'i seçme nedenleri:
* Yarı yapılandırılmış veri
* Dinamik veya esnek şema
* İlişkisel olmayan veri
* Karmaşık birleştirmelere ihtiyaç yok
* Birkaç terabayt (veya petabayt) veri depolama ihtiyacı
* Çok veri yoğun iş yükü
* IOPS için çok yüksek işlem kapasitesi
NoSQL'e uygun örnek veriler:
* Tıklama akışı ve günlük verilerinin hızlı alımı
* Sıralama veya puanlama verileri
* Geçici veriler, örneğin bir alışveriş sepeti
* Sıkça erişilen ('sıcak') tablolar
* Metadata/arama tabloları
##### Kaynak(lar) ve ek okuma: SQL veya NoSQL
* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs)
* [SQL vs NoSQL differences](https://www.sitepoint.com/sql-vs-nosql-differences/)
## Önbellek
<palign="center">
<imgsrc="images/Q6z24La.png">
<br/>
<i><ahref=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Kaynak: Scalable system design patterns</a></i>
</p>
Önbellekleme, sayfa yükleme sürelerini iyileştirir ve sunucularınız ile veritabanlarınıza olan yükü azaltabilir. Bu modelde, yönlendirici önce isteğin daha önce yapılmış olup olmadığını kontrol eder ve önceki sonucu bulmaya çalışır, böylece gerçek yürütümü kaydetmeye çalışır.
Veritabanları, okuma ve yazma işlemlerinin bölümler arasında homojen bir şekilde dağılımından genellikle fayda sağlar. Popüler öğeler, dağılımı bozarak darboğazlara neden olabilir. Bir önbelleği bir veritabanının önüne koymak, düzensiz yükleri ve trafiğin ani artışlarını absorbe etmeye yardımcı olabilir.
### İstemci önbelleği
Önbellekler, istemci tarafında (işletim sistemi veya tarayıcı), [sunucu tarafında](#ters-proxy-web-sunucusu) veya ayrı bir önbellek katmanında bulunabilir.
### CDN önbelleği
[İçerik dağıtım ağları (CDNs)](#içerik-dağıtım-ağı-cdn) aynı zamanda bir önbellek türü olarak kabul edilir.
### Web sunucusu önbelleği
[Ters proxyler](#ters-proxy-web-sunucusu) ve ([Varnish](https://www.varnish-cache.org/)) gibi önbellekler, statik ve dinamik içerikleri doğrudan sunabilir. Web sunucuları ayrıca istekleri önbelleğe alabilir ve uygulama sunucularına başvurmadan yanıtları döndürebilir.
### Veritabanı önbelleği
Veritabanınız genellikle genel bir kullanım durumu için optimize edilmiş varsayılan bir yapılandırmada bir düzeyde önbelleği içerir. Bu ayarları belirli kullanım modelleri için ayarlamak, performansı daha da artırabilir.
### Uygulama önbelleği
Memcached ve Redis gibi in-memory önbellekler, uygulamanız ile veri depolama arasında bulunan anahtar-değer depolama sistemleridir. Veri RAM'de tutulduğundan, veri disk üzerinde depolandığı tipik veritabanlarından çok daha hızlıdır. RAM, diskten daha sınırlıdır, bu nedenle [önbellek geçersiz kılma algoritmaları](https://en.wikipedia.org/wiki/Cache_algorithms), örneğin [en az kullanılan (LRU)](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)), 'soğuk' girişleri geçersiz kılmaya ve 'sıcak' veriyi RAM'de tutmaya yardımcı olabilir.
Redis aşağıdaki ek özelliklere sahiptir:
* Kalıcılık seçeneği
* Sıralı kümeler ve listeler gibi yerleşik veri yapıları
İki ana kategoriye ayrılmış birden çok önbellek düzeyi vardır: **veritabanı sorguları** ve **nesneler**:
* Satır seviyesi
* Sorgu seviyesi
* Tamamen oluşturulmuş(fully-formed) serilenebilir(serializable) nesneler
* Tamamen işlenmiş(fully-rendered) HTML
Genel olarak dosya tabanlı önbelleğe alma işleminden kaçınmaya çalışmalısınız; çünkü bu, çoğaltmayı ve otomatik ölçeklendirmeyi zorlaştırır.
### Veritabanı sorgu düzeyinde önbellekleme
Veritabanını sorguladığınız her zaman, sorguyu bir anahtar olarak kullanın ve sonucu önbelleğe depolayın. Bu yaklaşımın süresi dolma sorunlarına neden olabilir:
* Karmaşık sorgularla önbelleğe alınmış sonuçları silmek zordur.
* Tablodaki bir öğe gibi bir veri parçası değiştirilirse, değiştirilen öğeyi içerebilecek önbelleğe alınmış tüm sonuçların silinmesi gerekir.
### Nesne düzeyinde önbellekleme
Verinizi, uygulama kodunuzdaki objeler gibi düşünün. Uygulamanın veritabanındaki verileri sınıf örneklerine veya veri yapılarına birleştirmesine izin verin:
* Nesnenin temel verileri değiştiyse nesneyi önbellekten silin.
* Asenkron işleme izin verin: çalışanlar, önbelleğe alınmış en son nesneleri kullanarak nesneleri birleştirin.
Önbellekleme için öneriler:
* Kullanıcı oturumları
* Tamamen render edilmiş web sayfaları
* Aktivite akışları
* Kullanıcı grafik verileri
### Önbellek ne zaman güncellenmeli
Önbellekte yalnızca sınırlı veri depolayabildiğiniz için, kullanım durumunuza uygun bir önbellek güncelleme stratejisi seçmeniz gerekir.
#### Cache-aside
<palign="center">
<imgsrc="images/ONjORqk.png">
<br/>
<i><ahref=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Kaynak: From cache to in-memory data grid</a></i>
</p>
Uygulama, bellekten okumak ve yazmaktan sorumludur. Önbellek, doğrudan bellekle bağlantısı/etkileşimi yoktur. Uygulama, aşağıdaki işlemleri gerçekleştirir:
* Önbellekte veriyi arar; veri, önbellekte bulunmadığı için "cache miss" durumu oluşur.
* Veritabanından veriyi yükler.
* Bulunan sonuçları önbellekte saklar.
* İhtiyacı olunan veriyi döndürür.
```python
def get_user(self, user_id):
user = cache.get("user.{0}", user_id)
if user is None:
user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
if user is not None:
key = "user.{0}".format(user_id)
cache.set(key, json.dumps(user))
return user
```
[Memcached](https://memcached.org/) genellikle bu şekilde kullanılır.
Önbelleğe eklenen veriler çok hızlı okunur. Önbellek moduna tembel yükleme de denir. Yalnızca istenen veriler önbelleğe alınır; bu, önbelleğin istenmeyen verilerle doldurulmasını önler.
##### Dezavantaj(lar): cache-aside
* Önbellekte olmayan verileri talep etmek, verileri almak için üç adım gerektirir ve bu da önemli gecikmelere neden olabilir.
* Veritabanındaki veriler güncellenirse önbellekteki veriler güncelliğini yitirir. Bu sorunun, TTL'nin önbellek güncellemelerini veya doğrudan yazma modunu zorlayacak şekilde ayarlanmasıyla hafifletilmesi gerekir.
* Bir düğüm başarısız olduğunda, onun yerini yeni bir düğüm alır, bu da gecikmeyi artırır.
Uygulama, önbelleği ana veri deposu olarak kullanır ve veriyi okuma ve yazma işlemlerini buraya gerçekleştirir, bu sırada önbellek, veritabanına okuma ve yazma işlemlerini gerçekleştirmekten sorumludur:
* Uygulama, önbelleğe giriş ekler/günceller.
* Önbellek, girişi senkron bir şekilde veri deposuna yazar.
* Geri dönüş.
Uygulama kodu:
```python
set_user(12345, {"foo":"bar"})
```
Önbellek kodu:
```python
def set_user(user_id, values):
user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
cache.set(user_id, user)
```
Depolama ve yazma işlemleri nedeniyle, üzerine yazma yöntemi genel olarak çok yavaş bir işlemdir, ancak yeni yazılan verilerin okunması çok hızlıdır. Kullanıcılar genellikle veriyi okurken veriyi güncelleme sırasındaki gecikmeye daha toleranslıdır. Önbellekteki veriler eski değildir.
##### Dezavantaj(lar): üzerine yazma (write-through)
* Bir hata veya ölçeklendirme nedeniyle oluşturulan yeni düğümler, veritabanı güncellenene kadar önbelleğe alınmayacaktır. Cache-aside'in yanı sıra üzerine yazma yöntemini kullanmak, bu sorunu hafifletebilir.
* Yazılan verilerin çoğu hiç okunmayabilir, bu durum bir TTL ile minimize edilebilir.
Geri yazma yönteminde, uygulama aşağıdaki adımları gerçekleştirir:
* Önbelleğe giriş ekler/günceller
* Girişi veri deposuna asenkron bir şekilde yazarak yazma performansını artırır
##### Dezavantaj(lar): geri yazma (write-behind)
* Önbelleğin içeriği veri deposuna yazılmadan; önbellek devre dışı bırakılırsa veri kaybı olabilir.
* Geri yazma yöntemini uygulamak, cache-aside veya üzerine yazma yöntemini uygulamaktan daha karmaşıktır.
#### Önbelleği önceden yenileme (refresh-ahead)
<palign="center">
<imgsrc="images/kxtjqgE.png">
<br/>
<i><ahref=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Kaynak: From cache to in-memory data grid</a></i>
</p>
Önbelleği, süresi dolmadan önce erişilen herhangi bir önbellek girişini; otomatik olarak yenileyecek şekilde yapılandırabilirsiniz.
Refresh-ahead, önbelleğin gelecekte hangi öğelere ihtiyaç duyulma olasılığını doğru bir şekilde tahmin edebiliyorsa, okuma işlemine göre daha az gecikmeye neden olabilir.
##### Dezavantaj(lar): önbelleği önceden yenileme (refresh-ahead)
* Gelecekte hangi öğelerin muhtemelen ihtiyaç duyulacağını doğru bir şekilde tahmin edememek, refresh-ahead olmadan daha düşük performansa neden olabilir.
### Dezavantaj(lar): önbellek
* Önbellek ile veritabanı gibi gerçek kaynak arasındaki tutarlılığı sürdürmek için [önbellek geçersiz kılma](https://en.wikipedia.org/wiki/Cache_algorithms) gerekebilir.
* Önbellek geçersiz kılma, zorlu bir sorundur ve önbelleği ne zaman güncellemek gerektiğiyle ilgili ek karmaşıklıklar içerir.
* Redis veya memcached gibi öğeleri eklemek gibi uygulama değişiklikleri yapmak gerekebilir.
### Kaynak(lar) ve ek okuma
* [From cache to in-memory data grid](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast)
* [Scalable system design patterns](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html)
* [Introduction to architecting systems for scale](http://lethain.com/introduction-to-architecting-systems-for-scale/)
<i><ahref=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Kaynak: Intro to architecting systems for scale</a></i>
</p>
Asenkron iş akışları, maliyetli işlemler için talep sürelerini azaltmaya yardımcı olur ve aksi takdirde içeride gerçekleştirilecek olan işlemleri iyileştirir. Ayrıca, verinin periyodik olarak bir araya getirilmesi gibi zaman alıcı işleri önceden gerçekleştirerek de yardımcı olabilir.
### Mesaj kuyrukları
Message queues, mesajları alır, tutar ve iletiler. Bir işlem, içeride yürütülmek için çok yavaşsa, aşağıdaki iş akışını kullanarak bir mesaj kuyruğu kullanabilirsiniz:
* Bir uygulama bir işi kuyruğa gönderir ve ardından kullanıcıya iş durumu bildirilir
* Bir çalışan (worker), işi kuyruktan alır, işler, ardından işin tamamlandığını bildirir.
Kullanıcı engellenmez ve iş arka planda işlenir. Bu süre zarfında istemci, görevin tamamlandığı gibi görünmesi için isteğe bağlı olarak küçük bir işlem yapabilir. Örneğin, bir tweet gönderiyorsanız, tweet hemen zaman akışınıza gönderilebilir, ancak tweet'iniz gerçekten tüm takipçilere ulaşması biraz zaman alabilir.
**Redis** basit bir mesaj aracı olarak kullanışlıdır, ancak mesajlar kaybolabilir.
**RabbitMQ** popülerdir, ancak 'AMQP' protokolüne uyum sağlamanızı ve kendi düğümlerinizi yönetmenizi gerektirir.
**Amazon SQS** yüksek gecikme süresine sahip olabilir ve mesajların iki kez teslim edilme olasılığı vardır.
### Görev kuyrukları
Görev kuyrukları, görevleri ve ilgili verileri alır, bunları çalıştırır ve ardından sonuçlarını teslim eder. Zamanlamayı destekleyebilirler ve hesaplama yoğun işleri arka planda çalıştırmak için kullanılabilirler.
**[Celery](https://docs.celeryproject.org/en/stable/)** planlamayı destekler ve Python desteği sunar.
### Back pressure
Eğer kuyruk önemli ölçüde büyümeye başlarsa, sıra boyutu bellek boyutunu aşabilir. Bu durum, önbellek kayıplarına, disk okumalarına ve hatta performansın yavaşlamasına neden olabilir. [Back pressure](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-press-when-overloaded.html), kuyruk boyutunu sınırlandırarak bize yardımcı olabilir. Böylece, yüksek düzeyde işlemlerin korunmasını sağlayarak kuyruk verimini ve iyi yanıt süresini artırabiliriz. Kuyruk dolu olduğunda, istemci bir Sunucu Meşgul veya HTTP 503 durum kodu alacak ve isteği daha sonra, belki de [üstel geri çekilme](https://en.wikipedia.org/wiki/Exponential_backoff) ile yeniden denemek üzere tekrar deneyebilir.
### Dezavantaj(lar): asenkronizm
* Maliyetsiz hesaplamalar ve gerçek zamanlı iş akışları gibi durumlar, senkron işlemler için daha uygun olabilir, çünkü kuyrukların eklenmesi gecikmelere ve karmaşıklığa neden olabilir.
### Kaynak(lar) ve ek okuma
* [It's all a numbers game](https://www.youtube.com/watch?v=1KRYH75wgy4)
* [Applying back pressure when overloaded](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)
* [What is the difference between a message queue and a task queue?](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function)
## İletişim
<palign="center">
<imgsrc="images/5KeocQs.jpg">
<br/>
<i><ahref=http://www.escotal.com/osilayer.html>Kaynak: OSI 7 layer model</a></i>
</p>
### Köprü metni aktarım protokolü (HTTP)
HTTP, bir istemci ve bir sunucu arasında veri kodlama ve iletimi için bir yöntemdir. Bu, bir istek/yanıt protokolüdür: istemciler talepler gönderir ve sunucular taleplere ilişkin içerik ve tamamlama durumu bilgileri ile yanıtlar verir. HTTP, kendi içinde bağımsızdır, bu da taleplerin ve yanıtların birçok ara yönlendirici ve yük dengeleme, önbellekleme, şifreleme ve sıkıştırma işlemi yapan sunucu üzerinden geçmesine olanak tanır.
Temel bir HTTP isteği, bir fiil (metot) ve bir kaynak (nokta) içerir. Aşağıda yaygın HTTP fiilleri bulunmaktadır:
| POST | Bir kaynak oluşturur veya veriyi işleyen bir süreci tetikler | Hayır | Hayır | Evet,eğer yanıt taze bilgi(freshness info) içeriyorsa |
| PUT | Bir kaynak yaratır veya değiştirir | Evet | Hayır | Hayır |
| PATCH | Bir kaynağı kısmen günceller | Hayır | Hayır | Evet,eğer yanıt taze bilgi(freshness info) içeriyorsa |
| DELETE | Bir kaynağı siler | Evet | Hayır | Hayır |
**Birden çok kez çağrılabilir, ve farklı sonuçlar elde edilmeyecektir.**.
HTTP, **TCP** ve **UDP** gibi alt düzey protokollere dayanan bir uygulama katmanı protokolüdür.
#### Kaynak(lar) ve ek okuma: HTTP
* [What is HTTP?](https://www.nginx.com/resources/glossary/http/)
* [Difference between HTTP and TCP](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol)
* [Difference between PUT and PATCH](https://laracasts.com/discuss/channels/general-discussion/whats-the-differences-between-put-and-patch?page=1)
### İletim kontrol protokolü (TCP)
<palign="center">
<imgsrc="images/JdAsdvG.jpg">
<br/>
<i><ahref=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Kaynak: How to make a multiplayer game</a></i>
</p>
TCP, [IP ağı](https://en.wikipedia.org/wiki/Internet_Protocol) üzerinde bağlantı odaklı bir protokoldür. [El Sıkışma](https://en.wikipedia.org/wiki/Handshaking) yöntemi kullanılarak bağlantı kurulur ve sonlandırılır. Gönderilen tüm veri paketlerinin hedefe orijinal sırasıyla, zarar görmeden ulaşması aşağıdaki maddeler ile garanti edilir:
* Her paket için sıra numaraları ve [checksum alanları](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation).
* [Onaylama](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)) paketleri ve otomatik yeniden iletim
Eğer gönderici doğru bir yanıt almazsa, paketleri yeniden gönderir. Birden fazla zaman aşımı durumunda bağlantı kapatılır. TCP aynı zamanda [akış kontrolü](https://en.wikipedia.org/wiki/Flow_control_(data)) ve [tıkanıklık kontrolü](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control) de uygular. Bu garantiler gecikmelere neden olur ve genellikle UDP'den daha az verimli iletim sonuçları doğurur.
Yüksek verimlilik sağlamak için web sunucuları, büyük bir TCP bağlantısı sayısını açık tutabilir, bu da yüksek bellek kullanımına neden olabilir. Web sunucu iş parçacıkları ile örneğin bir [memcached](https://memcached.org/) sunucusu arasında çok sayıda açık bağlantıya sahip olmak maliyetli olabilir. [Bağlantı havuzu (connection pooling)](https://en.wikipedia.org/wiki/Connection_pool), uygun olan yerlerde UDP'ye geçişe ek olarak yardımcı olabilir.
TCP, yüksek güvenilirlik gerektiren ancak zaman açısından daha az kritik olan uygulamalar için kullanışlıdır. Bazı örnekler arasında web sunucuları, veritabanı bilgileri, SMTP, FTP ve SSH bulunur.
Aşağıdaki durumlarda UDP yerine TCP tercih ediniz:
* Tüm verilerin sağlam bir şekilde varmasına ihtiyacınız varsa.
* Ağ bant genişliğini otomatik olarak en iyi şekilde kullanmak istiyorsanız.
### Kullanıcı datagram protokolü (UDP)
<palign="center">
<imgsrc="images/yzDrJtA.jpg">
<br/>
<i><ahref=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Kaynak: How to make a multiplayer game</a></i>
</p>
UDP bağlantısızdır. Datagramlar (paketlere benzer) yalnızca datagram düzeyinde garanti edilir. Datagramlar hedeflerine sırasız veya hiç ulaşmayabilir. UDP, tıkanıklık kontrolünü desteklemez. TCP'nin sunduğu garantiler olmadan, UDP genellikle daha verimlidir.
UDP, datagramları alt ağdaki tüm cihazlara göndererek yayın yapabilir. Bu, [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) ile kullanışlıdır çünkü istemci henüz bir IP adresi almamıştır, bu nedenle TCP'nin IP adresi olmadan akış yapmasını engeller.
UDP daha az güvenilir olsa da, VoIP, video sohbet, yayın ve gerçek zamanlı çok oyunculu oyunlar gibi gerçek zamanlı kullanım durumlarında kullanışlıdır.
Aşağıdaki durumlarda TCP yerine UDP kullanın:
* Düşük gecikmeye ihtiyacınız var
* Verinin gecikmesi, veri kaybından daha önemli
* Kendi hata düzeltme yönteminizi uygulamak istiyorsunuz
#### Kaynak(lar) ve ek okuma: TCP ve UDP
* [Networking for game programming](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)
* [Key differences between TCP and UDP protocols](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)
* [Difference between TCP and UDP](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp)
* [Transmission control protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
* [Scaling memcache at Facebook](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf)
### Uzaktan yordam çağrısı (RPC)
<palign="center">
<imgsrc="images/iF4Mkb5.png">
<br/>
<i><ahref=http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview>Kaynak: Crack the system design interview</a></i>
</p>
Bir RPC'de, bir istemci genellikle uzak bir sunucuda olmak üzere farklı bir adres alanında bir prosedürün yürütülmesine neden olur. Prosedür, istemci programından sunucu ile iletişim kurma ayrıntılarını soyutlar şekilde kodlanmıştır, sanki yerel bir prosedür çağrısı gibi. Uzak çağrılar genellikle yerel çağrılardan daha yavaş ve güvenilir olabilir, bu nedenle RPC çağrılarını yerel çağrılardan ayırmak faydalıdır. Popüler RPC çerçeveleri arasında [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/) ve [Avro](https://avro.apache.org/docs/current/) bulunmaktadır.
RPC, bir istek-yanıt protokolüdür:
* **İstemci program** - İstemci tanımlama prosedürünü çağırır. Parametreler, yerel bir prosedür çağrısı gibi yığına itilir.
* **İstemci tanımlama prosedürü** ─ Prosedür kimliğini ve argümanları bir istek mesajına paketler (marshal).
* **Sunucu iletişim modülü** ─ İşletim sistemi, gelen paketleri sunucu tanımlama prosedürüne iletilir.
* **Sunucu tanımlama prosedürü** ─ Sonuçları açar (unmarshal), prosedür kimliği ile eşleşen sunucu prosedürünü çağırır ve verilen argümanları iletilir.
* Sunucu yanıtı, yukarıdaki adımları ters sırayla tekrarlar.
* Örnek RPC çağrısı:
```
GET /someoperation?data=anId
POST /anotheroperation
{
"data":"anId";
"anotherdata": "another value"
}
```
RPC, davranışları ortaya çıkarmaya odaklanmıştır. RPC'ler, genellikle iç iletişimde performans nedenleriyle kullanılır, çünkü kullanım durumlarınıza daha iyi uyan özelleştirilmiş çağrıları el ile oluşturabilirsiniz.
Aşağıdaki durumlarda yerel kitaplığı (yani SDK'yı) seçin:
* Hedef platformunuzu biliyorsunuz.
* "Mantığınızın" nasıl erişileceğini kontrol etmek istiyorsunuz.
* Kitaplığınızda oluşan hatalar üzerinde kontrol sahibi olmak istiyorsunuz.
* Performans ve kullanıcı deneyimi birincil endişeniz.
**REST** uyumlu HTTP API'ları, genellikle genel API'lar için daha sık kullanılır.
#### Dezavantajları: RPC
* RPC istemcileri, servis uygulamasına sıkı bir şekilde bağlı olur.
* Her yeni işlem veya kullanım durumu için yeni bir API tanımlanmalıdır.
* RPC'de hata ayıklanması(debug) zordur.
* Mevcut teknolojiyi kolayca değiştiremeyebilirsiniz. Örneğin, [RPC çağrılarının önbelleğe alınmasının](http://etherealbits.com/2012/12/); [Squid](http://www.squid-cache.org/) gibi bir önbellek sunucularında) uygun bir şekilde yapılması ek çaba gerekebilir.
### Temsili Durum Transferi (REST)
REST, bir istemci/sunucu modelini zorlayan bir mimari tarzıdır, burada istemci, sunucu tarafından yönetilen bir dizi kaynak üzerinde işlem yapar. Sunucu, kaynakların temsilini sağlar ve kaynakları ya manipüle edebilen ya da yeni bir temsil alabilen eylemleri içerir. Tüm iletişim durumsuz ve önbelleğe alınabilir olmalıdır.
RESTful arayüzün dört temel özelliği vardır:
* **Kaynakları tanımlama (HTTP'deki URI)** - herhangi bir işlemle ilgili olmaksızın aynı URI'yi kullanır.
* **Temsillemelerle değiştirme (HTTP'deki metotlar)** - metotları, başlıkları ve gövdeyi kullanır.
* **Kendi açıklamalı(Self-descriptive) hata mesajları (HTTP'deki durum yanıtları)** - Durum kodlarını kullanır, tekerleği yeniden icat etmeyin.
* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTTP için HTML arayüzü)** - Web servisiniz tarayıcıda tamamen erişilebilir olmalıdır.
Örnek REST isteği:
```
GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}
```
REST, veri sunmaya odaklanmıştır. İstemci/sunucu arasındaki bağı minimuma indirir ve genellikle genel HTTP API'leri için kullanılır. REST, kaynakları URI'lar aracılığıyla, [başlıklar](https://github.com/for-GET/know-your-http-well/blob/master/headers.md) aracılığıyla temsil edilme ve GET, POST, PUT, DELETE ve PATCH gibi metotlar aracılığıyla metotları açma konusunda daha genel ve birleşik bir yöntem kullanır. Durum bilgisi olmayan(stateless) yapısı nedeniyle, REST yatay ölçeklendirme ve bölütleme için uygundur.
#### Dezavantaj(lar): REST
* REST, veri sunmaya odaklandığından, kaynaklar doğal olarak düzenlenmiyorsa veya basit bir hiyerarşi içinde erişilmiyorsa iyi bir tercih olmayabilir. Örneğin, belirli bir etkinlik kümesiyle eşleşen son bir saat içinde güncellenmiş tüm kayıtları döndürmek, kolayca bir yol olarak ifade edilemez. REST ile muhtemelen URI yolu, sorgu parametreleri ve belki de istek gövdesinin bir kombinasyonuyla uygulanacaktır.
* REST genellikle kullanım durumunuza uymayan birkaç metoda (GET, POST, PUT, DELETE ve PATCH) dayanır. Örneğin, süresi dolmuş belgeleri arşiv klasörüne taşımak, bu metotların içine temiz bir şekilde sığmayabilir.
* Karmaşık kaynakları iç içe geçmiş hiyerarşilerle almak, tek bir görünümü oluşturmak için istemci ve sunucu arasında çok sayıda tur yapmayı gerektirir; örneğin, bir blog girişinin içeriğini ve o giriş üzerindeki yorumları almak vs. Değişken ağ koşullarında çalışan mobil uygulamalar için bu çoklu tur işlemleri istenmeyen durumlardır.
* Zamanla, bir API yanıtına daha fazla alan eklenebilir ve eski istemciler tüm yeni veri alanlarını, ihtiyaç duymadıkları halde alacakları için veri boyutunu şişirir.
* [Why REST for internal use and not RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508)
## Güvenlik
Bu bölümün biraz değiştirilmeye ihtiyacı var. [Katkı yapmayı değerlendirebilirsiniz](#katkı)!
Güvenlik geniş bir konudur. Eğer önemli bir deneyiminiz yoksa, güvenlik geçmişiniz yoksa veya güvenlik bilgisi gerektiren bir pozisyon için başvuruda bulunmuyorsanız, muhtemelen temel bilgilerden daha fazlasını bilmeye ihtiyaç duymayacaksınız:
* İletim ve dinlenme sırasında şifreleme kullanın.
* [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) ve [SQL enjeksiyonunu](https://en.wikipedia.org/wiki) önlemek için tüm kullanıcı girdilerini veya kullanıcıya açık parametreleri gizleyin.
* SQL enjeksiyonunu önlemek için parametreli sorgular kullanın.
* [En az ayrıcalık ilkesi](https://en.wikipedia.org/wiki/Principle_of_least_privilege)ni kullanın.
* [Security guide for developers](https://github.com/FallibleInc/security-guide-for-developers)
* [OWASP top ten](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet)
## Ek
Bazen sizden geçerli tahminler yapmanız istenecektir. Örneğin, diskten 100 görüntünün küçük resimlerini oluşturmanın ne kadar süreceğini veya bir veri yapısının ne kadar bellek gerektireceğini tahmin etmeniz gerekebilir. **İkinin kuvveti tablosu** ve **Her geliştiricinin bilmesi gereken bazı zaman verileri** bazı kullanışlı referans materyalleridir.
* [Latency numbers every programmer should know - 1](https://gist.github.com/jboner/2841832)
* [Latency numbers every programmer should know - 2](https://gist.github.com/hellerbarde/2843375)
* [Designs, lessons, and advice from building large distributed systems](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf)
* [Software Engineering Advice from Building Large-Scale Distributed Systems](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf)
### Diğer sistem tasarımı mülakat soruları
> Genel sistem tasarımı mülakat soruları, ve çözümleri
| Dropbox benzeri bir dosya senkronizasyon hizmeti tasarlayın | [youtube.com](https://www.youtube.com/watch?v=PE4gwstWhmc) |
| Google benzeri bir arama motoru tasarlayın | [queue.acm.org](http://queue.acm.org/detail.cfm?id=988407)<br/>[stackexchange.com](http://programmers .stackexchange.com/questions/38324/interview-question-how-would-you-implement-google-search)<br/>[ardendertat.com](http://www.ardendertat.com/2012/01/11 /implementing-search-engines/)<br/>[stanford.edu](http://infolab.stanford.edu/~backrub/google.html) |
| Google benzeri ölçeklenebilir web tarayıcısı(scalable web crawler) tasarlayın | [quora.com](https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch) |
| Google Dokümanlar'ı tasarlama | [code.google.com](https://code.google.com/p/google-mobwrite/)<br/>[neil.fraser.name](https://neil.fraser. ad/yazma/senkronizasyon/) |
| Redis benzeri anahtar-değer(key-value) deposu tasarlayın | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |
| Memcached'e benzer önbellekleme sistemi tasarlayın | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
| Amazon'a benzer öneri sistemi tasarlayın | [hulu.com](http://tech.hulu.com/blog/2011/09/19/recommendation-system.html)<br/>[ijcai13.org](http : //ijcai13.org/files/tutorial_slides/td3.pdf) |
| Bitly'ye benzer kısa bağlantı sistemi tasarlayın | [n00tc0d3r.blogspot.com](http://n00tc0d3r.blogspot.com/) |
| WhatsApp gibi sohbet uygulaması tasarlayın | [highscalability.com](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) |
| Instagram'a benzer fotoğraf paylaşım sistemi tasarlayın | [highscalability.com](http://highscalability.com/flickr-architecture)<br/>[highscalability.com](http://highscalability.com/blog/2011/ 12 /6/instagram-architecture-14-million-users-terabytes-of-photos.html) |
| Facebook'un zaman çizelgesi sistemini tasarlama | [facebook.com](https://www.facebook.com/note.php?note_id=10150468255628920)<br/>[highscalability.com](http://highscalability.com/ blog/ 2012/1/23/facebook-zaman çizelgesi-denormaliza.html'nin-gücüyle-size-getirildi) |
| Facebook'un sohbet sistemini tasarlayın | [erlang-factory.com](http://www.erlang-factory.com/upload/sunumlar/31/EugeneLetuchy-ErlangatFacebook.pdf)<br/>[facebook.com](https : //www.facebook.com/note.php?note_id=14218138919&id=9445547199&index=0) |
| Facebook benzeri grafik arama sistemi tasarlayın | [facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-out-the-infrastructure-for-graph- arama /10151347573598920)<br/>[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-indexing-and-ranking-in-graph-search/10151361720763920) <br/>[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-the-natural-language-interface-of-graph-search/10151432733048920) |
| CloudFlare gibi içerik dağıtım ağı tasarlama | [cmu.edu](http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci) |
| Twitter'a benzer trend konu sistemi tasarlama | [michael-noll.com](http://www.michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in- fırtına /)<br/>[snikolov .wordpress.com](http://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/) |
| Rastgele bir kimlik oluşturma sistemi tasarlayın | [blog.twitter.com](https://blog.twitter.com/2010/announcing-snowflake)<br/>[github.com](https://github.com/ twitter/kar tanesi/) |
| Belirli bir süre içinde en sık yapılan k isteklerini döndürün | [ucsb.edu](https://icmi.cs.ucsb.edu/research/tech_reports/reports/2005-23.pdf)<br/>[wpi. edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
| Birden çok veri merkezinden gelen verilerle bir hizmet sistemi tasarlayın | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |
| Çok oyunculu çevrimiçi kart oyunu tasarlayın | [indieflashblog.com](https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer- game.html)<br/>[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
| Borsa sistemi tasarlayın | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)<br/>[washington.edu](http: //courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) |
| Daha fazla sistem tasarımı sorunu ekleyin<br/> | [katkı](#katkı) |
### Gerçek dünya mimarileri
> Sistemlerin gerçekte nasıl tasarlandığına dair makaleler.
<palign="center">
<imgsrc="images/TcUo2fw.png">
<br/>
<i><ahref=https://www.infoq.com/presentations/Twitter-Timeline-Scalability>Kaynak: Twitter timelines at scale</a></i>
</p>
**Aşağıdaki makalenin ayrıntılarına odaklanmayın, onun yerine bunlara odaklanın:**
* Bu makalelerdeki ortak ilkeleri, teknikleri ve kalıpları keşfedin
* Her bileşenin hangi sorunları çözdüğünü, ne zaman kullanılacağını ve ne zaman kullanılamayacağını öğrenin
| Veri deposu | **Memcached** - Dağıtık bellek önbellek sistemi | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
| Veri deposu | **Redis** - Kalıcılık ve değer türleri ile dağıtık önbellekleme(distributed caching) sistemi | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |
| | | |
| Dosya sistemi | **Google File System (GFS)** - Dağıtık dosya sistemi | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/gfs-sosp2003.pdf) |
| Dosya sistemi | **Hadoop File System (HDFS)** - GFS'in açık kaynak kodu | [apache.org](https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html) |
| | | |
| Diğer | **Chubby** - Google'dan gevşek bağlı dağıtık sistemler için kilit hizmeti | [research.google.com](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf) |
| Diğer | **Zookeeper** - Senkronizasyonu sağlayan merkezi altyapı ve hizmetler | [slideshare.net](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) |
| | Daha fazla yazılım mimari örneği ekleyin | [katkı](#katkı) |
| ESPN | [Operating At 100,000 duh nuh nuhs per second](http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html) |
| Google | [Google architecture](http://highscalability.com/google-architecture) |
| Instagram | [14 million users, terabytes of photos](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html)<br/>[What powers Instagram](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances) |
| Justin.tv | [Justin.Tv's live video broadcasting architecture](http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html) |
| Facebook | [Scaling memcached at Facebook](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/key-value/fb-memcached-nsdi-2013.pdf)<br/>[TAO: Facebook’s distributed data store for the social graph](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/data-store/tao-facebook-distributed-datastore-atc-2013.pdf)<br/>[Facebook’s photo storage](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Beaver.pdf)<br/>[How Facebook Live Streams To 800,000 Simultaneous Viewers](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html) |
| Mailbox | [From 0 to one million users in 6 weeks](http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html) |
| Netflix | [A 360 Degree View Of The Entire Netflix Stack](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)<br/>[Netflix: What Happens When You Press Play?](http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html) |
| Pinterest | [From 0 To 10s of billions of page views a month](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html)<br/>[18 million visitors, 10x growth, 12 employees](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) |
| Playfish | [50 million monthly users and growing](http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html) |
| Tumblr | [15 billion page views a month](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) |
| Twitter | [Making Twitter 10000 percent faster](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster)<br/>[Storing 250 million tweets a day using MySQL](http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html)<br/>[150M active users, 300K QPS, a 22 MB/S firehose](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html)<br/>[Timelines at scale](https://www.infoq.com/presentations/Twitter-Timeline-Scalability)<br/>[Big and small data at Twitter](https://www.youtube.com/watch?v=5cKTP36HVgI)<br/>[Operations at Twitter: scaling beyond 100 million users](https://www.youtube.com/watch?v=z8LU0Cj6BOU)<br/>[How Twitter Handles 3,000 Images Per Second](http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html) |
| Uber | [How Uber scales their real-time market platform](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html)<br/>[Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) |
* [A distributed systems reading list](http://dancres.github.io/Pages/)
* [Cracking the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
## İletişim
Bu makaleyle ilgili eksiklikleri, soruları veya yorumlarınızı tartışmak için benimle iletişime geçmekten çekinmeyin.
İletişim bilgilerimi [GitHub ana sayfamda](https://github.com/donnemartin) bulabilirsiniz.
## Lisans
*Bu repodaki kodları ve kaynakları sizlere açık kaynak lisansı altında sağlıyorum. Burası benim kişisel arşivim olduğu için, koduma ve kaynaklarıma ilişkin aldığınız lisans, işverenimden (Facebook) değil; benim tarafımdan sağlanmaktadır.*
> Copyright 2017 Donne Martin
>
> Creative Commons Attribution 4.0 International License (CC BY 4.0)
