On 7 December 2005, Mark Zuckerberg joined CS50 for a guest lecture about Facebook and computer science. With Professor Michael D. Smith. Shared with permission.

***

HOW TO SUBSCRIBE

http://www.youtube.com/subscription_center?add_user=cs50tv

HOW TO TAKE CS50

edX: https://cs50.edx.org/
Harvard Extension School: https://cs50.harvard.edu/extension
Harvard Summer School: https://cs50.harvard.edu/summer
OpenCourseWare: https://cs50.harvard.edu/x

HOW TO JOIN CS50 COMMUNITIES

Discord: https://discord.gg/T8QZqRx
Ed: https://cs50.harvard.edu/x/ed
Facebook Group: https://www.facebook.com/groups/cs50/
Faceboook Page: https://www.facebook.com/cs50/
GitHub: https://github.com/cs50
Gitter: https://gitter.im/cs50/x
Instagram: https://instagram.com/cs50
LinkedIn Group: https://www.linkedin.com/groups/7437240/
LinkedIn Page: https://www.linkedin.com/school/cs50/
Quora: https://www.quora.com/topic/CS50
Slack: https://cs50.edx.org/slack
Snapchat: https://www.snapchat.com/add/cs50
Twitter: https://twitter.com/cs50
YouTube: http://www.youtube.com/cs50

HOW TO FOLLOW DAVID J. MALAN

Facebook: https://www.facebook.com/dmalan
GitHub: https://github.com/dmalan
Instagram: https://www.instagram.com/davidjmalan/
LinkedIn: https://www.linkedin.com/in/malan/
Quora: https://www.quora.com/profile/David-J-Malan
Twitter: https://twitter.com/davidjmalan

***

CS50 SHOP

https://cs50.harvardshop.com/

***

LICENSE

CC BY-NC-SA 4.0
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International Public License
https://creativecommons.org/licenses/by-nc-sa/4.0/

David J. Malan
https://cs.harvard.edu/malan
malan@harvard.edu

This afternoon I have the pleasure of introducing Mark Zuckerberg, which is 1 of our guest speakers this semester, to come and talk a little bit about computer science in the real world.

As most of you probably know, as you guys all do this much more than I do, founder of Facebook.com, which is a social networking program, whatever you want to call it, used it over 2,000 schools across the nation and possibly the world.

So good influence for doing some things in computer science.

He's going to tell us some of the background of it and what's been important and so forth.

So this is like 1 of the first times I've been to a lecture at Harvard.

So I guess what's probably going to be most useful for you guys if I just take you through some of the courses that I took at Harvard where I actually did go to lecture sometimes.

And sort of how different decisions that I had to make when I was moving along with Facebook got impacted by different stuff that I was learning in the classes that I was taking.

And if all goes according to plan, then maybe some of you guys will come out of this thinking that taking CS or engineering stuff at Harvard is actually sort of useful.

I think that this is slotted for 2 hours.

There's no way I'm going to speak for 2 hours.

I'll probably speak for like 20 minutes or 15 minutes.

And then I'll just let you guys ask questions, because I'm sure you guys have more interesting stuff to ask me than I can come up with to talk about myself.

So I guess I'll just kind of get started.

When I was here, I started off taking 121.

So I'm probably, you should have gotten the other guy who was doing Facebook, Dustin Moskovitz, who is my roommate.

When we got started, the site was written in PHP, which isn't something that you learn in 1 of these classes.

But fortunately, if you have a good background in C, the syntax is very similar.

So I started writing the site and launched it at Harvard in February 2004, so I guess almost 2 years ago now.

And within a couple of weeks, a few thousand people had signed up.

And we started getting some emails from people at other colleges asking for us to launch it at their schools.

And I was taking 161 at the time, so I don't know if you guys know the reputation of that course.

It was a really fun course, but it didn't leave me much time to do anything else with Facebook.

So my roommate Dustin, who I guess had just finished CS50, was like, hey, I want to help out.

I want to do the expansion and help you figure out how to do the stuff.

So I was like, that's pretty cool, dude, but you don't really know any PHP or anything like that.

So that weekend, he went home, bought the book Pearl for Dummies, came back, and was like, all right, I'm ready to go.

I was like, dude, the site's written in PHP, not Perl.

So he picked up PHP over a few days, because I promised that if you have a good background in C, PHP is a very simple thing to pick up.

So I mean, the first big decision that we really had to make was in how to kind of expand the architecture to go from the single school type setup that we had when it was just at Harvard to something that supported multiple schools.

So this was a decision that had to be made on a bunch of levels, both in the product and how we wanted privacy to work.

But I think that 1 really important decision that's helped us scale pretty well is how we decided to distribute the data.

So I don't know how much of complexity stuff and big O notation you guys do in this class.

So 1 of the most complicated computations that we do on the site is the computation to tell how you're connected to people.

Because you can imagine that stored as a series of undirected, unweighted pairs of ID numbers of people in the database.

Then if you want to figure out who's friends with someone, you have to look at all their friends.

But then if you want to figure out who's friends with someone, you have to look at all their friends.

But then if you want to figure out who's a friend of a friend or what the closest connection is there, then you kind of have to look at the 100 or 200 friends of each of those friends.

So it becomes, at each level, there's another factor of n multiplied in, where n is the number of friends that each of your friends has.

So you can see that this kind of becomes exponentially difficult to solve for the shortest path between people.

So if you're just looking for a friend of a friend that's n squared, if you're looking for a friend of a friend of a friend that's n cubed.

And that's something that traditionally was pretty difficult for a lot of the predecessor sites to Facebook.

And for example, Friendster had large problems with this because they were trying to compute paths 6 degrees out, or 7 degrees out.

And that's something that when you're doing n-seventh, that just is really, I guess, very hard.

So 1 of the things that we kind of had in mind when we were figuring out how to do this was how do you distribute the database in such a way that this computation becomes manageable?

So what we decided was that everyone on the site does most of their activity at the school that they're based at.

So if you're at Harvard, then most of the people who you're going to be seeing or transacting with on the site are going to be at Harvard.

It's actually probably like 90% of the stuff that you do on the site.

So we decided to split up the databases and create 1 instance of a MySQL database for each school on the network.

And in doing that, if you notice, the paths that we compute are only within the school.

So instead of, say, now we're at 6 million users, and instead of having to do n cubed over some portion of 6 million, it's just n cubed over 10,000, which is a much more manageable, I guess, type of computation.

So that was sort of the first big architectural decision that we had to make that contributed to us not dying a few months later.

So when we first set up the site, we had just 1 computer that we were running.

I kind of learned my lesson for trying to run a site out of my dorm room a few months earlier, and Harvard almost tried to kick me out.

So I ended up renting a server off site this time, and I guess running originally the database and the web server.

So Apache is what we were using in this instance to serve the pages from the same machine.

And because we distributed the databases in the way that we did, we were able to, as time went on, just add more machines linearly and sort of just grow the site without having any kind of exponential expansion on the amount of machinery that we had.

But after we hit, say, about 30 or 50 schools, we started realizing that we could start getting more performance out of MySQL or Apache.

And some of the way that stuff was set up just wasn't as optimal as it could be.

So for example, when you have MySQL machines and Apache machines on the same server, then if something happens to that server, then Not only does the database for that school or the schools on that server just stop responding in a way that will get you anything useful, but you can't even load any web pages.

But another issue is that the variance in the use from school to school is also not going to be perfect.

So I mean, some schools are always going to have heavier use.

I mean, we have schools now like Penn State that have 50,000 users.

And then the majority of the schools, I think, still have less than 2,000 users, just because there's a lot of small schools and a lot of schools that don't have complete ubiquity.

So in trying to deal with this issue and make it so that you could deal with the fact that Penn State had 50,000 people and just a ton of users all the time, and then you have some schools that don't.

What we decided to do is separate out some of the web servers from the database servers and make it so that we just had a pool of Apache web servers that we could load balance between and make it so that you can use those uniformly while just having the database layer be sort of consistent.

I don't know if this stuff is interesting to you guys at all, or if this is anything that matters to what you guys are studying now.

I mean, so if there's more stuff that you guys would rather know about in terms of the architecture, then I'll kind of leave that open to questions later.

So I'm just that I don't spend a lot of time just talking about random applications that you guys might not ever care to use.

But let me try to find some interesting examples.

So I guess 1 of the things that was pretty interesting was just sort of trying to, like, When we got to a point in terms of traffic where we started maxing out the performance of some of these open source applications that are generally pretty performant So, for example, MySQL is a really good open source database.

And I don't know if any of you guys in your own time mess around and make anything with MySQL or have used it in any way.

But it's pretty easy to use, and it's also decently quick.

It's not as fully featured as something like Oracle, but it's pretty good.

And we got to a point where I think around when we started doing maybe 100 million page views a day that we started running into some bottlenecks on that.

So for example, a typical query on MySQL might take like 2 to 4 milliseconds.

And, I mean, that's not that much, but like, when you're doing a hundred billion of page views a day, and each page view might have like 30 to 50 queries, I mean, especially if you're doing something like a profile view that just queries all kinds of different information, then that starts to suck.

So we started to develop a caching layer that allowed quicker access to some of the information.

And originally, we were using another open source application, Memcache, which I don't know if any of you guys have any experience with that.

It got access times down to, I guess, like 0.3 to 0.5 milliseconds, which is pretty good.

But it also has a bunch of distribution issues.

And it's supposed to be a distributed hash table application, where it's like you can just attach any number of memcache boxes in a cluster and be able to just hook it up and have it go.

But we sort of ran into a lot of issues there where different memcache boxes would go down and there was no redundancy on the information.

So when a memcache box went down and you had a cache miss, then all of a sudden you had a lot more traffic going to a specific set of databases, and that would suck.

So as time went on, we even outgrew memcache and the indices on MySQL.

And we still use that stuff, but we had to build on top of that extra redundancy.

And I think that's something that's probably maybe a little interesting.

But I'll let you guys ask me more questions about that later.

I'm not really sure what would be interesting to talk about right now.

I'm going to go to a class that's just a ton of tenor going into a phenomenal entertainment type.

But I felt the atmosphere was with big players already in the market and other big players where you thought you

So what your experience was with that, I think,

sort of ramp up and technically how do you see this as a business?

Yeah, so I mean, I think that like, so that's not a technical question at all.

I mean, so I guess I'll just like go into question time now.

Because like, I'm not really sure what's like relevant stuff for me to be discussing.

So I'll just answer this, and then anyone else who wants to ask me questions can just go for that.

I guess I never really spent a lot of time worrying about stuff like, I mean, there are companies out there like Google that could just sort of get into your space and do whatever you want at any time.

And I think that 1 of the cool things about this time in technology is that individuals are leveraged and able to do way more than they'd really ever been able to do before.

And even 4 years ago, when Google was started, now they have hundreds of thousands of machines and probably billions of dollars spent on equipment.

I think the generation before Google, you couldn't even make a site without some big piece of hardware.

And I think eBay, for example, ran off of 2

And it's like you just can't start doing that if you're just a kid in a dorm room.

So I think that The fact that we could rent machines for $100 a month and use that to scale up to a point where we had 300,000 users is pretty cool.

And it's a pretty unique thing that's going on in technology right now.

And it makes it so that instead of worrying about who's the big player and what is Google going to do next, you can do more of like, You could just get a lot of stuff done.

And instead of having to go out and have some of the traditional business problems, like you have to raise capital before you can make anything, that's no longer an issue.

So you're leveraged to do a lot more on your own now?

I don't know if that kind of answers the question that you're asking.

But I mean, it's 1 of the reasons why I think that at this point it makes a lot of sense to be studying this stuff.

Because at no point in the past could you leverage such a small amount of money to get powerful enough technology to really touch people in the way that you can today.

So Google does about 250 million page views a day.

They have hundreds of thousands of machines and 5,000 employees.

Facebook does 400 million page views a day.

And we have hundreds of machines, and we just passed 50 employees.

And that's just a technical generation of 3 or 4 years in the architectures that were created.

And then you go 3 or 4 years back before that from eBay to Google, and it's just completely different.

Because at least Google is running off of a lot of distributed equipment.

They have hundreds of thousands of machines, but the idea there was get a lot of shitty machines, you know, that are like really cheap.

And, I mean, that's a big step up, because then it's like, OK, that's more redundant, you know, and they're not losing information, they don't expect stuff to always work.

It's a much more mature attitude than eBay's, which was the only thing that they could do at the time.

I was just wondering if you've, like, I mean, have you released at all your extensions to memcache?

Because 1 thing I've noticed is that, yeah, there aren't really good available libraries for DHCP stuff.

But in terms of implementations that actually deal with all the redundancy issues and all those things.

A lot of the stuff that we didn't necessarily extend memcache, we built a bunch of stuff ourself.

And there's a lot of work that goes into making stuff open source.

It's on top of whether or not you want to lose the competitive advantage.

Because I think that if it were just easier to make something like that, then you could do it.

But then there's a lot of support and licensing and all that stuff.

We found that it's been kind of annoying.

I mean, 1 of the things that we actually considered making open source was this search server that actually that guy standing right there made while he was still out in California.

And I guess we got to a point where MySQL was lagging a little on some of the searches that we were trying to do.

And we decided that it would be a cool thing to do to just make a series of distributed machines that could kind of, he doesn't use a hash table.

What's the structure that you use, McCollum?

So I mean, yeah, we thought about making that open.

But then that's when we kind of had to do all this work to come up with a license.

And we're just like, all right, screw that.

But Yo Hiring people I Guess like when As you grow like the most important thing is to have smart people.

If you think about the technical leverage stuff that I was just talking about and answering that guy's question, As technology becomes more generic and less expensive, the leverage point becomes more in the people.

If you think about this from a perspective of a person to people time spent, or user time spent, or page view analysis.

It's like, because of technology now, people are much more leveraged to do more things and just be more important in the equation.

So because of that, it's really important to get the most intelligent people.

And also, I mean, it's like when you're a small company, then you can be really nimble and get a lot of stuff done.

And there's relatively little bureaucracy.

So if you have smart people who can take advantage of that to build cool things, then that's awesome.

I mean, I guess besides that, I don't know, designing new things.

There's not much corporate bureaucracy yet.

So I don't have to waste that much time on that.

How much have you spoken and consulted with lawyers so far?

I have a lawyer who works for me full time.

Would you recommend working on lawyers early on?

And that, I guess, provided some annoyance later on.

I guess Getting stuff set up really well is good.

And no one's ever going to tell you a lawyer's bad.

It's all just a question of opportunity cost and what you prioritize.

And I guess that In our case, it's like we now have to deal with a bunch of stuff that wasn't set up properly in the beginning.

But actually, most of that stuff is dealt with.

But instead of talking to lawyers early on, we were making stuff.

And I think that that was probably the right use of our time.

So I think that 1 cool characteristic of a lot of the companies that end up being really successful, not that we are really successful, but I guess we also fall into this bucket, is that they started off as someone trying to make something cool and not someone trying to make a company.

Google came out of Larry and Sergey's PhD dissertation at Stanford.

And Yahoo came out of, I guess, also some Stanford guys just kind of screwing around in their dorm room.

And eBay came out of like some guy trying to build a marketplace for his girlfriend to exchange Pez dispensers.

You know, Amazon was a little more calculated.

But like, but I mean, so I can't imagine that any of those people really had that much advice, and it seems to have worked out OK for them.

But at the same time, I'm not going to sit here and tell you not to get advice on stuff.

And a lot of times, people are just too careful, too.

I think it's more useful to make things happen and then apologize later than it is to make sure that you dot all your i's now and then just not get stuff done.

Facebook will reach a point where it could become that sort of big company that could be outfitted by a new idea, or it could become less agile, and it becomes too transparent?

Most companies are started on a couple of ideas.

And those are a few things that they do well.

So Yahoo's was like, we're going to organize all this information in the world by directory.

And that was what they started off doing.

And then they diversified out as time went on and built more stuff.

And a lot of that stuff is the core of their business now.

They didn't originally do search, and now directory just doesn't exist.

Google's big thing was just they did page rank.

And then, I guess, out of page rank, they have search.

And now they extend that to do other similar type of algorithms, searching in other spaces.

But you can tell how all the other stuff that they're doing is tangential.

And it's like they're trying really hard to make PageRank and other types of algorithms that are very similar to that work in their spaces.

It's just not as elegant or pure of an idea as the original 1 was.

So in Facebook, for example, when it just got started, What I thought was the most interesting thing was just to be able to type in someone's name and find out information about them.

I mean, there was hardly any of the stuff that was there now.

So, you kind of get started on some kind of core idea.

And generally, the company will do well, because I guess the people who are starting off working on that core idea kind of understand that single core idea in some sort of unique way.

But that doesn't imply that they have any better understanding of anything else than anyone else.

So that's why surrounding yourself with a lot of smart people is really important.

What was the various models that you used for the data to be able to upload the data down to the database?

I mean, there's a lot of applications on the internet now that do that stuff.

So I mean, Flickr is a pretty cool photo application.

Although I think in 3 weeks we passed them in the number of photos that we had on our site.

But I think that the coolest thing about photos is that you can tag them in the way that makes them link to people's profiles.

And I think that that's something that you can really only do if you have the context of everyone around you on the site.

That kind of requires a ubiquity of usage.

So I don't know if any of the other guys would have done that if they had that kind of use, but they didn't.

Don't any of you guys have any CS questions?

I'm curious, how do you decide as you're moving forward in the company to pursue a technology or not just pursuing a technology?

Do you have any processes in place to get a direct report of those types of things?

Or does technology come into the company just to be around themselves?

And somebody mentions something, you find out who it is, and that's the case?

See all CS50 transcripts on Youtube

CS50 Lecture by Mark Zuckerberg - 7 December 2005