Also, http://www.businessinsider.com/yelps-first-daily-deal-beats-...

If, OTOH, the slide you're producing are intended to be read, denser, more informational slides are appropriate.

As with most things in life, what to do depends on who your audience is.

You're not really saying anything at all, as far as I can tell.

OpenID because it's a non-solution to a non-problem, and OpenSocial because Google didn't provide developers with the primary benefit of the Facebook Platform (distribution).

Plus the social networks that implemented it were lame and didn't monetize well. OTOH, Playdom gor their start on MySpace.

http://techcrunch.com/2010/07/27/playdom-acquired-by-disney-...

If Google built a "game center" and let people send invites through gchat, we might be talking.

A simple back-of-the-envelope calculation shows that a freemium, subscription, or (uhm...) donation model won't work. We're talking six-figure revenue, most likely.

I guarantee you their current business model of modifying the SERPs and inserting links to Amazon and other affiliate programs is generating an order of magnitude more revenue than your proposed model would.

So, the situation is this: we have a product lots of people want. The naive business model (freemium) won't work -- a simple back-of-the-envelope calculation shows that.

What do you do? Go forward building a very popular product and look for a business model, or quit because you can't think of how to make money from day 1?

Facebook is six years old. 500MM people use it every month. They are profitable and do over $1Bn in revenue. They have a platform, on top of which there is at least one $1Bn company (Zynga).

Groupon, also a $1Bn company, owes its success in large part to Facebook's ad platform.

Facebook is now moving into location and online payments. They will compete with PayPal, another $1Bn company (before being acquired by eBay).

Zynga is PayPal's second largest merchant, after eBay itself. Through Facebook credits, Facebook will be taking 30% of each of those transactions. They are building a database of credit card numbers to do it.

Tencent QQ, a Chinese social network with gaming elements -- most of the popular genres on Facebook were taken from popular Chinese social games, e.g., the farming genre -- is 15 years old and did over $1Bn in revenue last year.

Tencent's IM product has 610MM monthly active users and 63.2MM people with subscription accounts.

http://www.tencent.com/en-us/content/ir/fs/attachments/inves...

When does this stuff stop becoming a fad?

Sure, fine, there's some universe in which Facebook vanishes tomorrow. The demand is still there. Social networking is here to stay.

The only way Facebook will fall behind is if they slow down and let someone else pass them, but given their history of aggressive and forward-thinking innovation, that seems unlikely for at least the next 5 years and/or until Zuckerberg stops caring.

And "it's popular because everyone else is doing it" -- you just described every business built on top of network effects. Craigslist is popular because everyone is using it. Does that make Craigslist a fad? eBay? VRBO? Etsy? YouTube? HN?

Pet rocks were a fad. Slap bracelets were a fad. Snuggies are a fad. http://fmylife.com is a fad.

Do you really think Facebook is that? Really?

I also notice that you didn't cite a single piece of data. Do you have any to support your argument, or is it just your "intuition?"

Even if you have to do it in the application layer, why would you need more than one SELECT? Just get the installed apps from the DB in a single query and do a set difference operation to only get the apps not already installed.

But I agree that putting the constraint in the DB layer is the correct solution. With MySQL you can just do INSERT IGNORE to only add apps not yet marked as being installed.

The first things I'd do: 1. Aggregate those inserts into a single SQL command. You never want to be issuing O(n) SQL queries per request.

2. Use InnoDB, not MyISAM, for the database engine. I assume it's MyISAM because he's talking about table locking. InnoDB has row-level locking, so you'll be able to INSERT and SELECT from a table concurrently.

I had a Facebook app with 20MM MAUs, and it worked fine with two machines. A component of the app was voting in polls, and I was processing ~10k votes per second. Each "vote" is an insert into a votes table.

Soo...not really sure how you go from "We're running too many INSERT queries and locking the tables!" to "Async queues and MongoDB!"