The Directory Structures of Big Tech: The Architecture of Code as Space

A software project's directory structure is the work of designing the space we call code. Just as an architect designs a building, it is the act of spatially organizing a codebase to fit each development organization's unique philosophy and culture. Big-tech companies like Meta (Facebook), Microsoft, and Amazon each have different development cultures and architectural philosophies, and the directory structures of the open-source projects they have created (for example, React, VS Code, and the AWS SDK) reflect those philosophies and cultures intact. Below, I'll look at each company's actual code directory structure and analyze how it connects to development culture, organizational structure, collaboration style, and architectural philosophy.

Facebook's (now Meta's) development culture is famous for its "Move Fast" spirit and open collaboration. One of the architectural philosophies that underpins this is the monorepo. A monorepo is an approach in which most of a company's code is kept in a single repository, and Meta in fact manages nearly all of its code in one enormous repository. By analogy, it is like a single giant building where countless teams gather to work under one roof, providing enough openness and transparency that every Meta developer can search and read the entire codebase, and even directly modify another team's code when needed. By opening up the space this way, Meta loosens the boundaries between teams and actively leverages Conway's Law (a system's structure reflects the structure of the organization) to energize collaboration.

Meta's monorepo philosophy is also baked into the directory structure of the open-source project React. If you look at the React GitHub repository, it takes a monorepo form in which many packages are gathered under a top-level directory called **packages/**. For example, React's submodules—packages/react, packages/react-dom, packages/scheduler, and so on—exist as separate folders, modularized within a single repository. The metadata needed for npm publishing (package.json and the like) all sits under this packages/ folder, taking a structure that manages the many React-related projects in one place. This structure makes it easy to maintain a consistent code style and to apply changes simultaneously, and Meta uses a single-version principle to reduce version mismatches and compatibility problems. In a monorepo, every package is built together at one version (based on the latest commit), so version conflicts between packages are eliminated at the root, and the consistency of the entire codebase is guaranteed at any commit point. This is also the solution that overcame the "hell" of package version conflicts that Meta developers experienced in the past in multi-repo environments.

Facebook also devised its own module system called Haste, a tool that makes it easy to relocate files within a massive codebase. In the Haste system, every file name is forced to be globally unique, and files are identified by module name rather than by path. Thanks to this, even when you move a file within the project, you can keep referencing it by the same module name without having to fix import paths. Through this kind of flexible module management, Facebook developers can nimbly reorganize directory structures and refactor code, which is in keeping with Facebook's hacker culture that encourages rapid experimentation and improvement.

To sum up, Meta's (Facebook's) directory structure can be seen as a form in which rooms are partitioned by module inside the enormous space of a monorepo. All the code lives in one space, but each module is partitioned into its own folder, and shared access to the whole building is guaranteed. This spatial design clearly demonstrates Facebook's open, collaborative development culture, along with an architectural philosophy that treats the entire codebase as a single mass while still pursuing modularization by part.

Microsoft's software development has traditionally emphasized systematic architectural layers and extensibility. This is well revealed in the directory structure of the open-sourced Visual Studio Code (VS Code) project. If you examine VS Code's codebase, the editor's core sits in the src/vs/ directory, and separately the extensions/ directory gathers the various built-in extensions. In other words, the **core** and the extensions areas are separated, so that the core is kept as lightweight a layered architecture as possible while the add-on features are split off like plugins. It is as if,

in a high-rise building, functional spaces were separated into a main building and a separate annex (extensions). The structure beneath VS Code's src/vs/ is built out of an even more finely divided layer structure. Microsoft divided the VS Code core into layers such as Base → Platform → Editor → Workbench → Code → Server,

into several tiers, with each directory responsible for a specific stratum of the software. For example, the base

layer provides the basic utilities and UI blocks used everywhere, and the platform layer holds the service architecture and the service definitions shared across layers. Above that, the editor layer holds the Monaco editor core (the text-editing engine), and the workbench layer holds the framework that makes it a full IDE—panels, the explorer, the menu bar, and more, beyond just the editor. At the top, code is the actual Electron-based desktop app entry point that ties everything together, and server serves as the server-side entry point for remote development. This layered separation gives each layer a clear area of responsibility

and makes it depend on the layers below while keeping coupling with the layers above as loose as possible. This reflects Microsoft's architectural philosophy of pursuing high cohesion and low coupling—when building software, too, it strictly applies a logical layered hierarchy, like the floor-by-floor structure of a building. VS Code's core is divided beneath src/vs into per-layer directories such as Base, Platform, Editor, and Workbench, and each layer has, underneath it, target-environment folders such as common, browser, node, and Electron (electron-browser/main). For instance, under vs/editor the common and browser directories are split,

with common separated out as the logic used in any environment and browser as the part that depends on the browser DOM API. By organizing code per environment this way, VS Code secured the portability to offer both desktop (Electron) and web (Web) versions from the same code base. VS Code also splits feature extensions off into extensions, and even its built-in features are implemented in per-extension directories under the extensions/ folder. This folder structure shows that VS Code aims for modular extensibility, and you can see a plugin-architecture philosophy in which new features are added as independent extensions and communicate with the core only through defined APIs.

Microsoft's collaboration style is also reflected in the structure and operation of the VS Code project. VS Code is developed entirely in the open on GitHub, with the Microsoft team and the community handling code and issues together. Even the project roadmap and the monthly development plans are published transparently in the repository, and it encourages open collaboration by accepting PRs from developers around the world. A well-organized directory structure and documentation make it easy for many outside contributors to take part in the project, which resembles Microsoft's tradition of valuing an organized, well-documented development culture. In short, VS Code's directory structure has a systematic layered hierarchy and clear module boundaries, and this can be called a design of code space that clearly reflects Microsoft's design-first ethos, its emphasis on extensibility, and its way of collaborating with the community.

Amazon's development organization is famous for its "two-pizza team" philosophy. This refers to a structure in which a team is kept small enough to be fed by two pizzas (a small elite group), and each team independently owns one service/product end to end. This organizational culture shows up in software structure as well, as a microservices architecture and a multi-repository strategy. Inside Amazon, each service generally has its own code repo and deployment pipeline, and by drawing clear boundaries between teams, each one develops at its own speed and cadence. By analogy, Amazon's codebase is like a village-style campus divided into several buildings on one campus, where each building (service) is owned and operated by its own team, and the buildings communicate only via roads (APIs). This approach promotes team autonomy and rapid innovation, but on the other hand, since services can each have different tech stacks or versions, maintaining consistency is also a challenge.

This philosophy of Amazon's is well revealed in the directory structure of the open-source project the AWS SDK. The AWS SDK is a library that deals with the cloud's countless services, and if you look at the latest **AWS SDK for JavaScript (v3)**, it has a structure modularized per service. The AWS SDK v3 is broken into more than 300 individual packages, providing one package for each AWS service such as S3, EC2, and DynamoDB. All of these packages are, on npm,

published individually in the form @aws-sdk/client-<service-name>; for example, the S3 client is @aws-sdk/client-s3

as a package, and DynamoDB is separated into the @aws-sdk/client-dynamodb package.

Thanks to this, developers can pick and use only the service modules their application needs, and since no unnecessary code is included, it is favorable for **slimming down (tree-shaking)**. This modular directory structure aligns exactly with Amazon's service-oriented organizational structure. Each service team can manage and evolve its own service's SDK module, and because the modules communicate through clear APIs, a change in one module does not directly affect another. This is

what could be called the code version of microservices, and it reflects Amazon's culture of maximizing team autonomy.

What's interesting is that in the implementation of AWS SDK v3, these hundreds of separated packages are nonetheless **managed together internally in a single repository (monorepo)**. Amazon uses tools like Lerna and Yarn Workspaces to develop the many packages as a single codebase, and chose an approach that publishes them as individual packages only at release time. This is fundamentally a strategy to capture both the development convenience of a monorepo and the deployment benefits of multiple packages. That is, during internal development all the SDK packages breathe in sync in one space, while the externally provided form becomes independent modules per service. Through this, Amazon systematically manages its large-scale distributed services while still offering customers a flexible library from which they can pick only the parts they need.

To sum up, Amazon's directory structure embodies a philosophy of modularization along service boundaries and distributed ownership. It divides the spatial design of code by service into independent buildings, and lets a small team freely remodel and extend each building. This can be called a case in which Amazon's two-pizza-team culture, its microservices orientation, and the flexibility that lets customers take only what they need are all projected onto the code structure.

As the saying goes, "code is architecture," and a software project's directory structure is permeated with the philosophy with which it treats the codebase and the organization's culture. Facebook revealed a hacker culture that values collaboration and speed by placing modules in the enormous open space of a monorepo; Microsoft embodied a philosophy of systematic design and platform extensibility through a layered structure and extension points; and Amazon expressed a culture that prioritizes team autonomy and independence above all through per-service modularization. If we likened each company's directory structure to a style of architecture, Facebook would be an open mixed-use complex, Microsoft a high-rise of sturdy structure, and Amazon a campus of diverse buildings gathered together.

Designing a directory structure is not merely tidying up code files; it is a deliberation over what kind of collaborative space you will create. In the end, good software architecture is doing the spatial design that fits the organization and the product, and into it dissolve developers' modes of communication, the boundaries and roles of teams, and a philosophy about how the system changes. In this sense, when you look at code through its directory structure, you can see that how the space called the codebase was designed also determines the ways the people working in it operate. Just as a building holds the life inside it, a directory structure is a vessel that holds the life of the code and collaboration inside it.

References: Meta's monorepo and collaboration culture (blog.3d-logic.com, blog.3d-logic.com), React's open-source structure (medium.com, medium.com), VS Code's layered structure and extension model (github.com, github.com), VS Code's open-source development approach (github.com), the AWS SDK's per-service packaging structure (aws.amazon.com, aws.amazon.com), Amazon's two-pizza teams and microservices principles (aws.amazon.com), and others.