- 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 ( ©myNoSQL)
J.Chris Anderson in an interview over ReadWriteWeb:
Klint Finley: Let’s start at the top: what exactly is Twebz? It’s described as a “decentralized Twitter client.” What exactly does that mean?
J Chris Anderson: The aim is to allow you to interact with Twitter when Twitter is up and you are online. But if Twitter is down for maintenance or you are in the middle of nowhere, you can still tweet. And when you can reach Twitter again, it will go through.
If lots of folks are using it, then they can see each other’s tweets come in even when Twitter is down.
Mostly the goal was to show the way on how to integrate CouchDB with web services and APIs.
A classical example of CouchDB powerful P2P replication capabilities. Dave Winer would probably be its ☞ biggest fan.
Original title and link: CouchDB Usecase: Decentralizing Twitter (NoSQL databases © myNoSQL)