-
Notifications
You must be signed in to change notification settings - Fork 10
componentLikeButton
The like button can be embedded by other websites. Entities within Metalcon also have a like button. Once a user clicks a like button the system will share this information with his social environment and subscribe the user to information provided by this entity.
Method | Signature | Description |
---|---|---|
log | log(uuid1, uuid2) | where uuid1 and uuid2 are entity-ids |
like (write) | like(uuid1, uuid2, VOTE.UP or VOTE.DOWN) | create new link between uuid1 and uuid2 in the social graph |
commons | getCommons(uuid1, uuid2) | retrieves all common entities (e.g. bands) between to given entities (e.g. users) |
like (read) | getIn(uuid) | retrieves all nodes to given entity (e.g. which entities likes me/are befriend with me) |
getOut(uuid) | retrieves all nodes from given entity (e.g. which entities do I like, are befriend with) |
10mio uri (big metal site has about 100k URI and we have about 100 metalsites.)
metalhammer has about 100 requests per second we assume metal hammer has 2.5% market share ==> 4k request per sec
we assume 1M metalfans in Germany (certainly it won't be more)
150B per request (64Byte cookie + 64Byte uri + timestamp + additional stuff)
HTTP Logging: 4k req / sec * 3600 s * 24 / day * 150 Byte --> 330MB logs pro tag --> 120 GB per year
This calculation comes down to 350 requests per user per day
this seems even large taking into consideration that in metal.de a user creates about 10 page views per visit.
Assuming that every metalcon user (see facebook stats on Wikipedia) fires 3 likes per day. This leads to following calculation: 1000M likes per year / (360 days * 24h * 3600s) --> aprox. 50 write requests triggered by likes
we did not take into consideration: 9k band websites and 2k venue websites
a band website could embed one global like-button or on each of their web pages.
###venue
max. 30 events per month --> aprox. 300 events per year --> 1 events (per day) * 2k venues --> 2k requests per day --> 85 requests per hour
- each event provides a like-button
- Fans: share information with social environment
- Fans: beginner friendly (metalcon already knows what content people surfed on in the past)
- Band / Venue: wants to know fans
- Band / Venue: Promotion
- University: usage behavior / high scaling system (handling many http requests is an interesting research question)
based on google indices
metal.de: 368.000 pages
- based on their media factsheet
- 352.000 PageImpressions / month -> 10000 per Day -> 10 per second
metal-hammer.de: 158.000 pages
- factsheet
- 4.918.812 PageImpressions / month -> 170000 per Day -> 120 per second
metal-inside.de: 83.000 pages powermetal.de: 437.000 pages metal1.info: 20.000 pages
- logging http access
- interaction with like button (like something retrieve friends who like!)
- retrieval: as often as http logging (only if user cookie is set)
- create: vary rare
- interaction with news feed
- building a strong (almost realtime) recommender system: http://ssc.io/deploying-a-massively-scalable-recommender-system-with-apache-mahout/
- data storage
- entry point (load balancer)
- stupid recommender
- (who of my friends likes this entities?)
- who in general likes this page (how many)
- AI recommender
- (you might also like … (friend, band, city, web site,...))
- how many estimated requests will have to be handled (read/write/disk access)
- what are the different domains/modules/services within this component
- on which services do the like-button rely on
- concerning security
- what are common attack vectors
- how to prevent them
- tracking users on different sites which implemented our metalcon like-button
- display like button with personal information
- obtain User ID
- gather context specific information
If user presses the like-button
- assign entity to users "preferences"
- maybe update newsstream of users friends
- Patrik