NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Spotify Architecture: The Peer to Peer Network

Spotify architecture

  • Spotify’s p2p network works like a BitTorrent network to locate peers […]. It uses a proprietary protocol designed especially for streaming music.
  • There’s no “preferred” peers or supernodes, but a future improvement might be to use peer-to-peer overlays to exploit the overlap in interests between users.
  • The maximum number of peers in the network is 60, with a soft-limit of 50 peers.
  • The client uploads to at most 4 peers at a time.
  • Server-side trackers and network queries are used to locate other users who have the music you’re listening to.
  • Spotify uses TCP as the transport protocol instead of UDP, since it can take advantage of TCP’s congestion controls and ability to re-send lost packets.
  • Most users have a large cache […]. This helps keep network traffic down since most users listen to tracks more than once.
  • At Spotify’s end, there’s a master storage area (290TB) and two production storage areas (90TB in London, 90TB in Stockholm).

How many characteristics of the distributed NoSQL databases can you identify in Spotify’s architecture?

Original title and link: Spotify Architecture: The Peer to Peer Network (NoSQL database©myNoSQL)