lombak şehidi

Problem: bit.ly gibi bir url shortening servisi tasarlayiniz. Requirements Ilk etapta requirements konusu cok detayli olarka aciga kavusturmamiz gerekiyor ki tasarimi yapabilelim. Diyelim ki su minvalde bir cozum isteniyor: Functional Requirements - Verilen bir URL'i kisaltip, calisan, unique bir kisa url olustur. - Bir kullanici bizim olusturdugumu kisa linki yizaret ettiginde, orjinal adrese yonlendir. - [Opsiyonel] Kullanici sisteme custom bir kisaltma onerebilmelidir  - Olusturulan link icin expiration zamani atanabilmeli Non-functional Requirements: - Sistem highly-available olmali - Rest API ile url olusturulabilmeli Back-of-the-envelope Hesabi On kabullerle birlestirerek asagi yukari ne kadar kaynaga ihtiyacimiz olacak bir bakalim. - Read-heavy bir sistem olacagi asikar. 100:1 (read/write orani kabul edecegiz) - Ayda 500 milyon url shortening requesti gelecek (demek ki aylik 50 milyar okuma olacak) - Ayda 500 milyon write (36 * 24 * 3600 saniye) => 200 Url / saniye yazma

 Malesef trade-off'a guzel bir Turkce karsilik bulamadim. Vardi birtane ama hatirlayamiyorum suanda. Nyese. Scalability camiasinda hersey bir trade-off. Yani bir yerden kazaniyorsan baska bir taraftan kaybediyorsun. En baslica 3 cesit tradeoff var.  1. Performance vs Scalability - Sistem sadece bir kullanici icin bile yavas ise, performans problemi var demektir. - Sistem bir kullanici icin hizli ama kullanici sayisi artinca yavasliyor ise, scalability problemi var demektir. Peki bu ikisi nasil bir trade-off teskil edebilyor? Su makalede cok guzel ifade etmis: One thing that tripped me up early on in my career was the difference between performance and scalability. At first I thought they were exactly the same. I was quite surprised when my first project to scale a system actually made my code run slower.  Normal 1 kullanici icin cok performansli bir sistemi alip, scalable yaptigimizda, yine sadece 1 kullanici icin test edersek, belki performansin bir miktar dustugunu gorebiliriz.

Problem Asagidaki ozellikleri (feature) destekleyecek sekilde scalable bir mesajlasma servisi tasarimi yapiniz: - Birebir mesajlasma (Gonderildi / Iletildi / Goruldu notifikasyonlari) - Last seen ozelligi Cozum  1. Birebir mesajlasma  Ornegin Bob, Alice'e mesaj gonderiyor olsun. Bunun olabilmesi icin oncelikle Bob'un bir sunucuya bagli olmasi gerekir.  Client - server baglantisi Belki de son soyleyenecek seyi en basta soyleyelim. Sunucular ile kullanicilar WebSockets protokolu uzerinden haberlesecekler. Neden? Cunku bir noktada, sunucunun direk olarak client'a mesaj gondermesi gerekiyor. Http ile bu mumkun degildir. Http protokolu sadece clienttan sunucuya istek gonderilmesi ve sunucunun da bir cevap dondurmesi uzerine kuruludur. Durup dururken bir server size mesaj gonderemez. Client tarafinda long polling yapilabilir ama bu da hem realtime olmaz hem de sunucuya gereksiz cok fazla request atilmis olunur. Client-server baglantisi TCP uzerinde calisan WebSockets ile yapilac

Soru Bize Twitter'in sistem tasarimini yapiniz. Ozellikler: - Tweet'leme - Timeline goruntuleme     Kullanici timeline (bir kullanicinin attgini tum tweetlerin listesi)     Home timeline (siz twittere girdiginizde gordugunuz timeline. takip edilen kullanicilarin attiklari tweetlerden olusur.) - Kullanici takip etme Cozum Ilk olarak yine naive cozum ile baslayabiliriz. Ilk akla gelen yontem, tweet'leri bir tabloda saklamak. Buna ek olarak kullanicilar tablosu ile join de yapilarak timeline'lar olusturulabilir. Users table'in primary key'i de UserId uzerinden joinleniyor. Seklinde bir Tweets tablosu bir de Users tablosu olusturdugumuzu dusunelim. Bu durumda bir tweet ile kullanici arasinda 1'e : n bir iliski olur. Yani bir kullanici icin birden fazla tweet kaydi bulunabilir.  Bu durumda bir kullanici kendi ana sayfasina gittigi zaman, home timeline'i nasil olusturacagiz?  1- Kullanicinin takip ettigi kullanicilari bulacagiz 2- Bu kullanicilarin attiklari t

Scalability postunda bircok onemli noktaya degindik. Burada sadece birkac ufak ek yaparak, bundan sonraki postta ornek system design'lara gececegiz.  Cogu public servis bir load balancer arkasinda calisan birden fazla web server tarafindan serv edilmektedir. Bu sayede yuk artisina bagli olarak otomatik horizontal scaling yapmak mumkundur. Bir kullanici birinci requestte webserver #1 tarafindan cevaplanmis olabilir, ikinci requesting de webserver #2 tarafindan cevaplanmis olabilir. Kullanici ilk olarka hangi server ile muhattap oldugundna bagimsiz olarak tum web serverlar tarafindan ayni sekilde requestleri karsilanabilmelidir. Bunu yapabilmek icin: Altin Kural : Tum webserver'lar ayni kodu calistirmali ve session datasi barindirmamalidir. Yani tamamen stateless olmalidir. Session datasi harici merkezi bir database veya persistent cache'te tutulmalidir.  Deployment Burada bir zorluk var. O da webserver kodunda bir guncelleme yaptigimiz zaman nasil deploy edelim ki ayni and

Bir websitesi host ettigimizi dusunelim. Gidecegimiz yer bir hosting sirketi olacaktir. Bu hosting sirketi genellikle birden fazla musteriyi belki de ayni makine uzerinde host etmektedir. Birgun gelip de web sitemiz cok populer olursa, artik bu donanim ile web siteye erisim imkansiz ya da cok yavas bir hale gelebilir. Burada iki secenek var: 1- Vertical scaling: Yani daha fazla ram, cpu, disk. Elimizdeki donanimi artirmak. Ornek olarak fazladan bir cpu core'a sahip olmak demek, ayni anda birden fazla requeste gercekten paralel olarak cevap verebilmemize olanak taniyacaktir. Tek bir cpu core ile paralel islem yapmak olanaksizdir. Simdilerde bulmak zor ama tek core olan bilgisayarlarda bile ayni anda birden fazla is yapabiliyoruz. Ama aslinda isletim sistemi her bir uygulama icin cpu'dan sirayla hizmet aliyor ve biz bunu paralelmis gibi algiliyoruz.   Ancak burada bir limit var. Bir bilgisayarin donanimini en fazla belirli bir olcude artirabilirsiniz. Bir noktadan sonra maliyerl