Facebook doing things that don't scale

In the pantheon of tech startups that changed the world, Facebook stands as one of the most transformative. From its humble beginnings in Mark Zuckerberg’s Harvard dorm room to becoming a global platform with billions of users, Facebook’s journey is well-documented. What’s less known, however, is how the company’s early technical architecture—specifically its school-by-school server approach—exemplifies the startup principle of “doing things that don’t scale” to achieve initial growth and success.

The Harvard Beginning

Facebook (initially called “TheFacebook”) launched on February 4, 2004, as a social network exclusively for Harvard students. The initial version was remarkably simple by today’s standards—a basic website built with PHP, running on a single rented server that handled both the web server (Apache) and the database (MySQL). This setup was adequate for a small user base confined to a single university, but it wouldn’t remain that way for long.

The platform’s popularity exploded almost immediately. Within 24 hours of launch, over 1,200 Harvard students had signed up. Within a month, more than half of the undergraduate population had created profiles. This rapid adoption created both an opportunity and a challenge for Zuckerberg and his small team: how could they expand to other universities without overwhelming their limited infrastructure?

The Expansion Challenge

As Facebook’s popularity grew at Harvard, students from other universities began clamoring for access. Zuckerberg recognized the potential for growth but faced a significant technical hurdle. The social networking features that made Facebook valuable—particularly the ability to see connections between users—required complex calculations that would become exponentially more difficult as the user base expanded.

The most computationally intensive operations involved calculating “friends of friends” relationships. For a small network like Harvard, with a few thousand users, these calculations were manageable. But if Facebook simply opened its doors to everyone at once, the system would need to perform these calculations across millions of users, potentially bringing the entire platform to a crawl.

This was not a theoretical concern. Friendster, an earlier social network, had faced precisely this problem. As Zuckerberg would later explain in a 2005 lecture at Harvard’s CS50 computer science course, Friendster attempted to calculate connections several degrees out (essentially trying to identify connections through “six degrees of separation”), which put enormous strain on their systems and led to performance issues that ultimately contributed to the platform’s decline.

The Unscalable Solution: Database Partitioning by School

Rather than building a massive infrastructure upfront or limiting the platform’s functionality, Zuckerberg and his team came up with an elegant, if unscalable, solution: they would partition their database by school, creating separate instances for each university they added to the network.

This approach was based on a key insight about user behavior: most interactions on Facebook occurred between students at the same school. Harvard students primarily connected with other Harvard students, Stanford students with Stanford students, and so on. By creating separate database instances for each school, Facebook could contain most of the complex “friends of friends” calculations within a much smaller dataset—typically just a few thousand users rather than millions.

As Michael Cheng, an early Facebook engineer, explained: “Partitioning the database was a critical step in allowing us to scale. It meant we weren’t constantly bogging down the system searching through a massive pool of data.”

This segmentation strategy aligned perfectly with Facebook’s expansion plans. Rather than opening the platform to everyone at once, they added new schools one by one, creating a new database instance for each. This controlled rollout allowed them to manage growth, ensure a good user experience, and maintain the exclusivity that made Facebook appealing in the first place.

The Rollout Strategy

Facebook’s expansion followed a deliberate sequence:

1. Harvard First (February 2004): The platform launched exclusively at Harvard, allowing the team to test and refine the core functionality.
2. Elite Universities (March-April 2004): Facebook expanded to other Ivy League schools—Columbia, Stanford, Yale, and others—creating separate database instances for each.
3. More Universities (September 2004): By the start of the fall semester, Facebook had expanded to most major U.S. universities, still maintaining the school-by-school approach.
4. High Schools (September 2005): The platform eventually opened to high school students, again using the same partitioning strategy.
5. Corporate Networks (May 2006): Facebook created networks for workplaces, continuing the pattern of segmentation.
6. Global Opening (September 2006): Finally, Facebook opened registration to anyone with an email address, having built the infrastructure and experience needed to handle a global user base.

This gradual, controlled expansion was not just a marketing strategy—it was necessitated by the technical architecture. Each new school added to the network required setting up and configuring a new database instance, a process that couldn’t be fully automated or scaled. It required manual work from the small engineering team, exemplifying the principle of doing things that don’t scale.

Technical Implementation Details

The school-by-school architecture had several key components:

Database Partitioning

Each school had its own MySQL database instance, containing the profiles, connections, and activity data for students at that institution. This horizontal partitioning (also known as sharding) allowed Facebook to distribute the data across multiple databases, preventing any single database from becoming overwhelmed.

When users performed actions that required accessing data from their own school’s network—like browsing profiles or checking friend connections—the system would query only the relevant database instance, keeping response times fast and server load manageable.

Cross-Network Interactions

While most interactions occurred within school networks, Facebook did need to handle some cross-network scenarios, such as when students from different schools became friends. These cases required more complex queries that accessed multiple database instances, but they were relatively rare compared to within-network interactions.

The system was designed to prioritize performance for the most common use cases (within-network browsing) while still supporting less frequent cross-network interactions, even if they were somewhat slower.

Separation of Web and Database Servers

As Facebook grew, even with the database partitioning strategy, the single-server setup became inadequate. The team separated the web servers (running Apache and PHP) from the database servers (running MySQL), creating pools of web servers that could be balanced across multiple machines.

This separation of concerns meant that if a database server experienced issues, the web servers could still serve pages, and vice versa, increasing the platform’s overall reliability.

Caching Implementation

To further improve performance, Facebook implemented Memcached, an open-source distributed memory caching system. This allowed them to store frequently accessed data in memory, reducing the load on the databases and speeding up response times.

As one former Facebook engineer noted, “Memcached was a game-changer for us. By storing frequently accessed data in memory, we significantly reduced the load on the database servers. This improved performance and responsiveness for our users.”

The Limitations and Evolution

While the school-by-school architecture served Facebook well in its early days, it had clear limitations that would eventually necessitate a more scalable approach:

Manual Configuration

Each new school added to the network required manual setup and configuration, a process that couldn’t be fully automated. As Facebook expanded to hundreds and then thousands of schools, this became increasingly burdensome for the small engineering team.

Data Silos

The partitioned databases created data silos that made it difficult to perform analytics or implement features that required a global view of the network. As Facebook’s ambitions grew beyond simply connecting college students, these limitations became more problematic.

Cross-Network Performance

As more users formed connections across different schools, the performance of cross-network interactions became a growing concern. The system was optimized for within-network browsing, but as the platform evolved, cross-network interactions became increasingly important.

Infrastructure Management

Managing a growing number of database instances required significant operational overhead. Each instance needed to be monitored, backed up, and maintained, creating a complex infrastructure that became increasingly difficult to manage as the platform scaled.

Recognizing these limitations, Facebook gradually evolved its architecture. As the company grew and hired more engineers, they developed more sophisticated approaches to data partitioning and distribution. They moved away from the school-based partitioning to more flexible sharding strategies based on user IDs or activity patterns, allowing for more efficient data distribution and better support for global features.

The transition wasn’t immediate or easy—it required significant engineering effort and careful migration of data to ensure continuity of service. But it was necessary for Facebook to achieve its ambition of connecting the entire world, not just college students.

The Business Impact

The school-by-school architecture had profound implications for Facebook’s business strategy and growth:

Controlled Growth

By adding schools one by one, Facebook could manage its growth rate, ensuring that the platform remained stable and responsive as it expanded. This controlled approach allowed them to build a solid foundation of users and refine their product before opening it to a broader audience.

Exclusivity and Desirability

The limited access created a sense of exclusivity that made Facebook more desirable. Students at schools that didn’t yet have access would eagerly await their turn, creating pent-up demand that translated into rapid adoption when access was finally granted.

Network Effects Within Communities

By focusing on building dense networks within individual schools before expanding, Facebook leveraged powerful network effects. Once a critical mass of students at a school joined the platform, it became almost essential for others to join as well, driving organic growth.

Word-of-Mouth Marketing

The school-by-school approach facilitated word-of-mouth marketing, as students would tell friends at other schools about the platform. This organic, grassroots promotion was far more effective than any advertising campaign could have been.

Building a Moat

The strategy also helped Facebook build a competitive moat. By the time they opened registration to everyone in 2006, they had already established dominant positions in the most valuable demographic markets—college students and, later, high school students. This made it difficult for competitors to gain traction.

Lessons for Startups

Facebook’s school-by-school server architecture offers several valuable lessons for startups:

1. Embrace Unscalable Solutions

Facebook’s approach was inherently unscalable—manually setting up and configuring database instances for each new school could never work for a global platform with billions of users. But it was perfect for the stage they were at, allowing them to grow in a controlled manner while maintaining quality.

As Paul Graham of Y Combinator famously advised, startups should “do things that don’t scale” in their early days. Facebook’s story is a perfect example of this principle in action.

2. Align Technical Architecture with User Behavior

Facebook’s database partitioning strategy was based on a deep understanding of how users actually used the platform. By recognizing that most interactions occurred within school networks, they could design an architecture that optimized for these common cases while still supporting less frequent cross-network interactions.

This user-centric approach to technical architecture is a powerful lesson for startups: build your systems around actual user behavior, not theoretical use cases.

3. Use Technical Constraints to Shape Business Strategy

Rather than viewing their technical limitations as obstacles, Facebook turned them into strategic advantages. The need to add schools one by one became a feature, not a bug, creating exclusivity and driving demand.

Startups often face technical constraints, especially in their early days. The lesson from Facebook is to embrace these constraints and let them shape your go-to-market strategy in positive ways.

4. Prioritize Performance for Core Use Cases

Facebook’s architecture prioritized performance for the most common use cases—within-network browsing and interaction—even if it meant some trade-offs for less frequent scenarios. This focus on optimizing the core experience, rather than trying to be equally good at everything, allowed them to deliver a fast, responsive platform with limited resources.

5. Be Willing to Evolve

While the school-by-school architecture served Facebook well in its early days, the company didn’t cling to it when it no longer made sense. As they grew and their ambitions expanded, they evolved their architecture to support their new goals.

This willingness to abandon approaches that worked in the past but won’t scale for the future is crucial for startups as they grow.

The Legacy of Facebook’s Approach

Today, Facebook’s infrastructure bears little resemblance to the simple, partitioned architecture of its early days. The company now operates massive data centers around the world, using sophisticated distributed systems to serve billions of users.

But the legacy of that early approach lives on in the company’s DNA. The willingness to do things that don’t scale, to focus on building dense networks within communities before expanding, and to align technical architecture with user behavior—these principles helped Facebook grow from a dorm room project to a global platform.

For startups today, Facebook’s school-by-school server architecture stands as a powerful reminder that sometimes the best way to build something massive is to start small, focus on serving a specific community exceptionally well, and be willing to do the manual, unscalable work required to create a solid foundation.

In a world obsessed with scalability and automation from day one, Facebook’s story is a refreshing counterpoint—a reminder that even the most successful tech giants started with solutions that wouldn’t scale, but were perfect for the moment they were in.