Spotify Altyapısına teknik bir bakış – 2

Selamlar,

Geçenlerde Spotify Backend mimarisini merak edip, biraz araştırıp, karşıma çıkan ve kayda değer gördüğüm birçok gönderiyi harmanlayıp bir şeyler karalamıştım. 1. bölümü kaleme almak bana teorik ve pratik anlamda çok şey kattı. Kendimi bir Newbie olarak konumladığım bu ortamda,  yüzeysel de olsa hakkında fikir sahibi olup, “bu da bu işe yarıyormuş” diyebileceğim birçok kavramı öğrenmiş oldum. Öğrenmiş oldum” diyorum, çünkü çoğu konuyu ben de anlık araştıra araştıra öğreniyorum, yorumluyorum ve notluyorum. Günün sonunda bu notlardan da güzel bir makale ortaya çıkıyor. Araştırıp geliştirme yapabilmenin en temel öğesi sanırım “Motivasyon“.  Makalenin geri dönüşlerinden de anlıyorum ki, benim gibi Spotify arayüzünden favori şarkısını seçip dinleyen, dinlemekle de kalmayıp işin arka yüzünü merak eden birçok kişi mevcut. Profesyonel arkadaşları tenzih ediyorum. 🙂

Motivasyon

Öncelikle neden Spotify? Bu sorunun çok net bir cevabı var bende. Sahip olduğu tecrübeyi paylaşmaktan korkmayan bir şirket bu. Geliştirdikleri ürün, Feature, Infrastructure, Tool her ne varsa bunlar hakkında derinlemesine paylaşım yapmaktan çekinmiyor bu insanlar. Konferanslarda, Meetup‘larda, Youtube‘da, Reddit‘te, Quora‘da, Stack Overflow mecralarında ve daha birçok yerdeler. Github hesabından da bu durumu tescilleyebiliyoruz. Bir taraftan bu insanları izlerken, yazılarını okurken ister istemez aklımdan geçenler şunlar;

  • Olaya sadece Spotify olarak bakmayıp, büyük ölçekte bir projenin bileşenleri neler?
  • Milyonlarca kullanıcıya sunulan servislerde kullanılan araçlara, terimlere, tekniklere ve jargona yabancı kalmamak
  • Öğrenilen her yeni bir open-source komponent’ten ilham alıp bunları ihtiyaç halinde kendi yapımda, projemde veya mimarimde kullanabilmek
  • Infrastructure Trend teknolojiler hakkında bir şeyler kapabilmek, yorumlayabilmek

Hadi yapıyı incelemeye kaldığımız yerden devam edelim!

Büyük düşünmek!

Yapıyı derinlemesine incelemeye devam etmeden önce, bilgilerimizi tazelemek istiyorum. Böylesine bir geniş çaplı uygulamayı geliştirmeden önce dikkate almamız gereken başlıkları tekrar belirtelim;

  • Uygulama milyonlarca kullanıcıya Scale olabilmeli
  • Uygulama cross platform çalışabilmeli, bütün platformlar desteklenmeli (IOS, Android, Windows, Mobile/Desktop, Linux)
  • Uygulama karmaşık iş modeli gereksinimlerinin altından kalkabilmeli
  • Uygulama piyasadaki rakiplerine karşı rekabetçi olabilmeli, şartlara hızlı tepki verebilmeli, yenilikleri ile fark yaratıp rakiplerinin önünde olabilmeli (out-innovate)

Bütün bu gereksinimler dikkate alındığında Spotify infrastructure’ın temel odak noktasının “Otonom” odaklı bir yapı olduğu görülüyor. “Otonom” kavramı her şeyin kendi kendini yönetmesi anlamına gelse de, bir şeylerin “bağımsız” bir şekilde hareket özgürlüğüne sahip olması anlamına da geliyor. “Bağımsız ve özgür” sözcüklerinin birazdan açıklayacağım Spotify yapısındaki “Squad” kavramı ile nasıl vurgulandığını göreceğiz. Her şeyin ufak servislere bölündüğü bu ortamda “Otonom” kilit sözcük.

Bu makalede kısaca incelenecek başlıklar

  • Features & Squads (Takımlar)
  • Spotify System-z
  • Partitioning, Feature Services
  • Provisioning, Storage Yönetimi, Servisler arası mesaj yönetimi ve kapasite planlama
  • DNS, Service Discovery, SRV kayıtları ile trafik yük paylaşımı

Yine,  Spotify altyapısı hakkında okuduğum ve dağıtık mimarilere atıfta bulunan çok güzel bir makaleden alıntılar ve birebir çeviriler ile başlamak istiyorum. Makale, 2013 yılında Gösta Forsum (Big Data Engineer) tarafından yazılımış ve mimari hakkında net bilgiler veriyor.

Features, Squads ve Partitioning kavramları

~600 developer,  ~100 takım, 1 ürün!

Kullanıcıların hacmini handle etmek isteyen herhangi bir mimari gibi Spotify da bu problemi parçalara ayırarak (Partitioning) çözmüş. Durumu çok basit bir yaklaşımla anlatırsak, Spotify Client üzerinde görülen/etkileşilen her bir fiziksel bölüm farklı Spotify Squad tarafından sahipleniliyor. Squad sözcüğü yabancı gelmiş olabilir. Squad, Spotify Jargonunda takımların ismi. Her bir takıma “Squad” deniliyor. Spotify Client üzerinde sunulan her Feature ayrı bir Squad tarafından yönetiliyor.

squad.JPG

SOURCE: https://www.jfokus.se/jfokus16/preso/Modelling-Microservices-at-Spotify.pdf

Eğer bir Feature fail olursa, kullanıcılar diğer Feature’ları kullanmaya devam ederler. Feature’lar birbirlerinden bağımsız olarak çalışırlar. Diyelim ki, bir Feature ile diğer herhangi bir Feature arasında zayıf bir bağımlılık var. Bir Feature’ın fail olması bir diğerinin fail olmasına yol açabilir ama bütün Spotify Servislerinin durmasına neden olmaz.

sparch

SOURCE: https://labs.spotify.com/2013/03/15/backend-infrastructure-at-spotify/

Belirli bir Feature üzerindeki bütün bilgilerden tek bir Squad sorumlu olduğundan  bu servislerdeki A/B testleri oldukça kolaylaşmakta. Squad’ın toplanan dataları inceleyerek  Feature üzerinde mantıklı kararlar vermesi de keza aynı şekilde yapılmakta. Feature partioning işlemi güvenilirlik, ölçekleme ve ekip çabalarına odaklanmanın en etkili yolu.

Bütün Feature’ları bölümlemek ve yetenekli Squad’lara teslim etmek birçok faydanın yanında sorunları da beraberinde getirmekte. Bu takımları destekleyecek bir Insrastructure nasıl geliştirilmeli? Bu takımların, diğer takımların işlerini engelleme riski olmadan hızlı geliştirme yapabildiklerinden nasıl emin olmalıyız? Altyapının küresel ölçekte Scale edilmesi sorununu nasıl çözeriz?

Çoğu organizasyonda Veri tabanı yönetimi için Database Adminstrator’lar, Data Center donanım yönetimi için Operasyon departmanı mevcut. Yaklaşık 100 Squad‘ın (yaklaşık 600 developer) eş zamanlı olarak servis talep ettiği bir ortamda bu birimler darboğaz yaşayacaklardır. Spotify bu sorunu aşmak için Backend Infra’sını tamamen Self Service olarak geliştirmiş. Buradaki “Self Service”in anlamı herhangi bir Squad Organizasyonun geri kalanı ile etkileşimde bulunmadan kendi Live ortamında geliştirme yapabilir ve bu ortamı yenileyebilir. Kulağa hoş geliyor değil mi?

Spotify System-Z ile tanışın!

cockpit-100624_960_720

Hakkında çok bilgi bulamasam da, şu linkteki videoda ve şu sunumda System-z hakkında bir nebze olsun bilgiye ulaşabildim. System-z’nin görevi System Metadata‘lar için merkezi bir yönetim sağlamak. Peki, System metadata veya teknik metadata nedir? Teknik metadatalar yapı ile ilgili teknik anlamdaki bütün metadataları saklarlar. Örneğin; bir ilişkisel veritabanının sahip olması gereken data tiplerini, tablo yapılarını, alanları, boyutları veya data mining modelleri gibi. Teknik metadatalar kullanıcı tarafından görüntelenecek olan data modellerini, raporları, schedule yapısını, dağıtım listelerini ve kullanıcı güvenlik izinlerini tanımlarlar.

Screenshot_1

SOURCE: https://www.slideshare.net/kevingoldsmith/microservices-at-spotify

System-z,  servis ile ilgili komponent bilgilerini tutar, depencency (bağımlılık) takibini yapar, deployment’ları yönetir, sahiplik ve alerting işlemlerini organize eder. Aynı zamanda System-z ile servis monitoring dashboard’lar konfigure edilir, sistem ile ilgili aktiviteler (login, system updates) kontrol edilir. Donanım provision işlemleri de buradan yapılır.

systemz

Searchview servisi ile ilgili detayların yönetildiği bir System-z ekranı.

search

System-z’nin diğer yeteneklerini de inceleyelim. Şu harika PDF dosayası ile bu özelliklerin çoğuna ulaşabiliyoruz. Bütün Spotify Infrastructure’ın Orkestrasyonunu yapan bu  gelişmiş merkezi yönetim aracının diğer hayret verici özellikleri şu şekilde;

  • Mevcut eski servisleri yeni servislere 2 dakikadan daha az bir şekilde migrate edebilir ve birçok System-z feature ile birlikte kullanıma sunabilir.
  • System-z “New Service” özelliği sayesinde yeni bir backend servisi saniyeler içinde oluşturabilir. Herhangi bir Jenkins instance’ına doğru bir build pipeline oluşturabiliriniz.
  • Bir servisin bütün dependency’lerini suanbilir. Daha derine inip bunlara ait bağımlılıkları da aktarabilir.
  • Anlık olarak Hermes kullanan bir servisin nerede deploy edildiğini raporlayabilir.
  • System-z ana sayfası, bir takıma ait bütün sistem komponentlerini gösterir. Squad’lar System-z ile servislerini yönetir.
  • En kritik özelliklerden biri de, production ortamında çalışan bir instance’ın konfigürasyon dosyası ile mecvut konfigürasyon dosyaarı incelenebilir. Hatalar kolayca tespit edilebilir.

Fully Self Service Infrastructure

Infrastructure yapısını bu aşamaya getirebilmek için Spotify birçok farklı alanda  bir dizi sorunla uğraşmak zorunda kalmış. Hadi bu sorunlara bir göz atalım.

  • Provisioning (Servislerin Deploy edilmesi)
    • Bir Squad, yeni bir Feature geliştirirken genellikle bu servisi birkaç farklı lokasyona deploy etme ihtiyacı duyar. Bunu sağlamak için Spotify’ın geliştirdiği Infrastructure ile Squad, bu servisin Spotify’ın kendi Data Center‘ına mı Deploy edileceğine yoksa Cloud ortamına mı Deploy edileceğine karar verebilir. Buradaki en önemli faydalardan biri de, geliştirilen Spotify Infrastructure sayesinde mevcut Data Center ile Servislerin yayınlanacağı Public Data Center Environment farklılıklarını minimize etmek. Yani Dahili Data Center ile Public Cloud ortamının aynı olmasını sağlamak. Public Cloud sayesinde donanımların provision edilmesi ve dinamik ölçekleme (dynamic scaling) işlemleri daha hızlı gerçekleşebilmekte. Yine Cloud sayesinde Spotify Client’lar kendilerine en yakın Data Center’lara erişebilmekte.
    • siterepl
      SOURCE: https://labs.spotify.com/2013/03/15/backend-infrastructure-at-spotify/
  • Storage 
    • Spotify’da çoğu Feature bir tür depolama alanı gerektirir. Örneğin Spotify Client üzerindeki “Follow” özelliği. Bir Feature için gerekli olan Storage çözümü geliştirmek, milyonlarca kullanıcının bunu kullanacağı düşünüldüğünde çok kolay bir görev olmayacaktır. Bu durumda bir çok farklı şey göz önüne alınmalıdır. DataErişim Pattern‘leri, Site’lar arası Fail Over durumu ve yük devralma durumları, Kapasite tabii ki, Tutarlılık, Backup‘lar, Site’lar arası veri bozulmaları durumu. Bu kriterler göze alındığında hepsini karşılayacak kolay bir çözüm yoktur. Her özellik için, özellikten sorumlu Squad ihtiyaç duyulan Storage çözümünü geliştirmek zorundadır. Spotify altyapısı bu durumda birkaç farklı Storage opsiyonu sunar. Cassandra, PostgreSQL ve Memcached. Bu çözümler hakkında kısa özet bilgileri bir önceki bölümde vermiştim. Eğer, geliştirilen Feature’ın Data ihtiyacı bölümlenmiş bir data ise, bir Squad, servisi geliştirirken “Sharding” implemente etmek zorundadır. Ancak birçok servis Site’lar arası data replikasyonuna da ihtiyaç duymaktadır. Bu konuda çözüm Cassandra’dır. Site’lar arası, Fail Over destekli, Replike halde bir Storage Cluster implementasyonu yapmak oldukça karmaşık bir işlem.  Özellikle de Cassandra’nın veya PostgreSQL’in Multi Site kullanımı, kurulumu ve yönetimi.
  • Messaging (Mesajlaşma)
    • Spotify Client’ları ve Backend servisleri Request/Reply, Messaging ve PubSub paradigmalarını kullanarak haberleşir. Spotify, kendi düşük gecikmeli bir mesajlaşma katmanı geliştirmiş. Bu sistem yüksek teslim etme garantili, “Failover Routing” ile kesintisiz çalışabilen, yük dengeleyiciye sahip bir mesajlaşma sistemi.
  • Capacity Planning (Kapasite Planlama)
    • Spotify’ın giderek büyümesi, Backend yapısına doğru artan bir trafiğe neden olur. Her Squad mevcut yükün Scale edilmesi noktası emin olmak zorundadır. Her takım, kendi servisine doğru akan trafiği manual monitör edebilir ve gerektiğinde darboğaz anında Scale yapabilir. Bu şekilde manual Scale’in yanında Spotify Infrastructe, Squad’lara  yük altındaki servislerini otonım bir şekilde Scale edebilme izni de verir. Otomatik Scale sistemi sadece darboğaz anlarında çalışır. Bir seviyeden sonra trafiğin manual olarak izlenmesi gereklidir.

graph

SOURCE: https://labs.spotify.com/2013/03/15/backend-infrastructure-at-spotify/
  • Isolation (Diğer servislerden yalıtım)
    • Yeni bir Feature veya Servis geliştirildiğinde, geliştirilen bu servisler diğerlerini çağırma ve haberleşme eğilimindedir. Spotify geliştirme ortamında Squad’ların hızlı hareket etmesi ve bunu yaparken de Spotify’ın diğer parçalarını negatif olarak etkilememeleri çok önemlidir. Bunu önlemek için, Messaging katmanı bir rate-limit ve yetkilendirme sistemine sahiptir. Rate-Limit’ler bir default threshold’a yani eşiğe sahiptirler. Bu değerler bir Squad’ın bir şey denemek için diğer servislerle haberleşmesine izin verir.  Eğer, Spotify üzerinde ağır bir trafik yükü bekleniyorsa, Squad’lar ortak olarak bu durumu koordine eder ve bu trafiği birlikte nasıl handle edecekleri konusunda anlaşırlar. İzolasyonun bir diğer önemli konusu ise şu, farklı Feature’lar, farklı sunucu veya sanal makinelerde çalışırlar. Bunun en önemli nedeni, bir servisin bozulduğunda diğerini etkilememesidir.

Eski teknolojilerin yükselişi

Böylesine bir dağıtık mimaride Spotify, eski ve kendini kanıtlamış farklı teknolojiler de kullanıyor. Yazılım geliştirmede kullanılacak doğru araçların zamanla kendini kanıtlaması gerektiğini savunuyor. Örneğin bir Backend servisi Go ve Node.JS ile geliştirmek yerine Java veya Python tercih etmek, ya da dataların saklanması için MongoDB veya Riak yerine MySQL veya PostgreSQL tercih etmek bu duruma birkaç örnek. İş için Doğru “tool” seçimi hem zaman hem de ekonomik anlamda kritik öneme sahiptir.  Spotify’da Lead Security Engineer olarak çalışan Björn Edström‘ın makalesinde doğru tool seçimi ile ilgili güzel bir örnek veriyor. Örneğin mevcut Storage ihtiyacı için seçilen tek bir ürün mevcut yük için mantıklı olabilirken gelecekte artan kullanıcı miktarı nedeni ile ihtiyaç duyulacak bir diğer Storage çözümü mantıklı gelebilir. İhtiyaçlar belirlenirken gelecekteki durum da dikkate alınmalıdır.

Sıkıcı teknolojiler DNS ve Bind

Bakmayın sıkıcı dediğime, Spotify Squad’ları da DNS ve Bind’ın sıkıcı olduğunu kabul ediyorlar ama yıllanmış, olgunlaşmış, güvenilirliği kanıtlanmış bu teknolojileri tam da mimarinin göbeğinde yani “Service Discovery” yükünü handle etmek için kullanmışlar.

Durumu hemen açıklayalım. DNS, Spotify mimarisinde oldukça yoğun kullanılan bir teknoloji. “DNS” dendiğinde çoğu insanın aklına ilk gelen şey kesinlikle “A” kayıtlarıdır.  Yani hostname kayıtlarını IPv4 adreslerine map yapan kayıtlar. Ama, DNS bir telefon adres defterinden çok daha fazlasıdır. Spotify’ın gözünde DNS, bir dağıtık, replike olabilen, hata tolere edebilen bir Veri tabanı.

DNS ile Service Discovery

Service Discovery” kavramı aslında epeyce geniş bir kavram ama özünde bu kavramın amacı şu soruya cevap vermektir; “Bu servis hangi sunucuda çalışır?”  Spotify mimarisinde DNS tam da bu sorunu çözmekte. Özellikle de SRV kayıtları bu noktada önemli bileşenler. bir DNS SRV kaydı standart bir söz dizime sahip bir kayıttır. Örneğin bu form şu şekildedir:

“_name._protocol.site ” bu kayıt ağırlık(weight), öncelik(priority) ve bir port numarası ile bir sizi hostname’e map edilir. Bu durumu bir örnek ile açıklayalım.

Örneğin, Spotify Client bir Access Point’e (Client’ın Spotify Backend’ine erişim noktası) bağlandığında Client bir SRV kaydına bakar. Bu SRV kaydı:

“_spotify-client._tcp.spotify.com. “ şeklindedir.  Access Pointler her Backend Servise bir şeyler yapmak üzere istekler gönderir. Örneğin bir SRV kaydının map edildiği sunucuları şu şekildedir.

$ dig +short _spotify-client._tcp.spotify.com SRV
10 12 4070 A1.spotify.com.
10 12 4070 A2.spotify.com.
10 12 4070 A3.spotify.com.
10 12 4070 A4.spotify.com.

Yukarıda görülen bir satır, sırasıyla Öncelik, Ağırlık, Port numarası ve hostname’e karşılık gelir. Servisi kullanacak Client, bir grup server içerisinden en yüksek önceliğe sahip bir sunucuya yönlendirilir. Bir servisi çalıştıran bütün sunucular down olduğunda sadece en düşük priority’e sahip sunucuya istek gönderilir.

Konuyu biraz daha açıklayalım; örneğin yukarıdaki kayıtlarda 4 hostname’de aynı priority’e (10) ve aynı ağırlığa (12) sahip. Böylece her biri bütün trafiğin sadece %25’ini handle ederek yük paylaşımı yaparlar.

srv

SOURCE: https://www.slideshare.net/protocol7/spotify-architecture-pressing-play

Spotify’da her şey bir SRV DNS kaydına sahiptir. Buna önceki bölümde de değinmiştim. Spotify’ı ayakta tutan bütün Backend servisler doğru SRV kayıtları sorgulanarak keşfedilebilir durumdadır. Buna “Service Discovery” diyoruz. Bu aynı zamanda bir servisin diğer bir servisi nasıl bulabildiğini de açıklar. Bununla birlikte DNS’in uygun olmadığı case’ler de mevcuttur. Örneğin, bazı dışarıya direkt açık servisler,  HTTP servisleri gibi. Bazı Client’lar direkt HTTP isteği göndererek bağlanmak istedikleri Access Point’lere bağlanabilirler.

srv2

Nadir de olsa, bazı durumlarda Spotify CNAME ve PTR kayırlarını da SRV kayıtlarına ek olarak kullanabilmektedir. Bu, bir single sunucunun tek bir amaca hizmete ettiği durumlarda ortaya çıkar. Örneğin bir PTR kaydı, bir database cluster’ının master sunucusunu işaret edebilir.

Yönetim amaçlı olarak da bir çok tool ve Infrastructure  projesi geliştirilmiştir. Örneğin SRV kayıtlarının yönetimini kolaylaştıran bir bir komut satırı uygulaması ya da bir DNS Cache olarak çalışan bir web servisi.  Spotify GitHub hesabında bu tür araçlara ulaşmak mümkün.

DNS, yüksek performanslı bir dağıtık database olduğundan, Spofity, DNS’i bir konfigürasyon datalarını saklayan servis olarak da kullanmakta. Önceki bölümde bahsettiğim DHT yani Distributed Hash Table’ların ring bilgilerini TXT DNS kayıtlarında tutulduğunu bu makaleden öğreniyoruz.

$ dig +short +tcp _spotify-tracker-internal._hm.lon.spotify.net SRV | sort | head -n 4
5000 5000 4301 lon2-tracker-a1.lon.spotify.net.
5000 5000 4301 lon2-tracker-a2.lon.spotify.net.
5000 5000 4301 lon2-tracker-a3.lon.spotify.net.
5000 5000 4302 lon2-tracker-a1.lon.spotify.net.

$ dig +short +tcp config._spotify-tracker-internal._hm.lon.spotify.net TXT
“slaves=:0” “hash=sha1”

$ dig +short +tcp tokens.4301.lon2-tracker-a1.lon.spotify.net. TXT
“0555555555555555555555555555555555555555”
“8555555555555555555555555555555555555555”

DNS çok özel bir servis. Genellikle eski ve core bir Infrastructure servisi olduğundan insanlar pek DNS hakkında konuşmazlar. Genelde bir “Outage” durumu yaşandığında insanlar DNS’ten şikayet ederler. 🙂 Yukarıda görüldüğü gibi Spotify, DNS’i biraz farklı şekillerde kullanıyor. DNS çözümü olarak BIND tercih edilmiş. Resolve, Recursive sorgulama, DNS Cache Resolver olarak da Unbound uygulaması kullanılmış.

8-srv_lookup-01-01

DNS’in Spotify mimarisindeki konumunu inceleyelim. Yapıda “Stealth Primary” adında bir tipik bir BIND kurulumu var, amacı ZONE kayıtlarını yönetmek. Buna bağlı olarak da bir Standby durumda yedekli kurulumlar mevcut, gerektiğinde yükü devralmak üzere. Bu sunuuclar arkasında bir dizi “Authoritative NameServer” BIND sunucular mevcut. Bunların diğer adı Secondary BIND sunucular. Bu “Secondary” sunucular coğrafi olarak konuşlanmış ve en az 2 adet konuşlandırılmıştır. Bunlardan her konumda 4 tanesi halka açıktır. Öndeki “Stealth Primary” Zone dosyalarını derledikten sonra bu dosyalar isim sunucularına transfer edilir.  Bu coğrafik Auth NameServer sunuculara bağlı “Unbound” sunucular mevcut. Bu sunucular her data center içinde en az 2 tanedir. Amacı Cache ve Recursive DNS sorgularını handle etmektir. Bu Resolver sunucuların her biri Authoritative NameServer sunucularla konuşacak şekilde konfigüre edilmiştir. Böylece redundancy sağlanır.  Mimarinin en arkasında bulunan her serviste bir tane konuşlu unbound server mevcuttur. Servisin bulunduğu site’ı çözebilmek için kullanılırlar. Bütün bu  yapı ile Service Discovery mekanizması rahatça çalışır. Unbound’lar herhangi bir servis üzerine gelen DDoS odaklı birçok isteği engellemeye yardımcı olur.

Bugünlük bu kadar. Infrastructure problemleri yaşamadığınız güzel bir hafta diliyorum. 🙂

Teşekkürler.

Hakan Orcan

Kullanılan kaynaklar:
https://www.jfokus.se/jfokus16/preso/Modelling-Microservices-at-Spotify.pdf
Backend infrastructure at Spotify
https://en.wikipedia.org/wiki/A/B_testing
https://en.wikipedia.org/wiki/Metadata
https://us.pycon.org/2013/schedule/presentation/185/
https://github.com/google/protobuf
https://github.com/gevent/gevent
https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
In praise of “boring” technology
http://www.unbound.net/
https://www.dnsknowledge.com/whatis/authoritative-name-server/

https://www.slideshare.net/protocol7/spotify-architecture-pressing-play

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s