Distributed File System — Naive (Single NFS-Like Server)

Designing a distributed file system is one of the most fundamental system design interview questions because it forces candidates to reason about data durability, fault tolerance, storage scalability, and the separation of metadata from data. The naive single-server approach is where every candidate should start — it establishes the baseline that makes the improvements in distributed architectures measurable and concrete.

The core challenge is storing and retrieving files reliably at scale. In the naive approach, a single FileService handles all operations: upload writes the file to local disk and records metadata (file ID, filename, size, SHA-256 checksum, disk path) in a PostgreSQL database. Download queries the metadata from PostgreSQL, reads the file from local disk, and streams it to the client. List queries the filename column with a LIKE prefix match. Delete removes the file from disk and the metadata row from the database.

The naive approach has four fatal limitations that interviewers expect candidates to identify. First, storage capacity is bounded by a single machine's disk — typically 16 TB with NVMe SSD. When the disk fills up, the only option is a larger disk or a new server with manual data migration. There is no horizontal scaling. Second, there is zero fault tolerance: a single disk failure, server crash, or filesystem corruption causes permanent data loss for every file on that machine. Enterprise disks have a 1-2% annual failure rate, so data loss is a statistical certainty over time. Third, all I/O flows through one server's disk controller and network interface, creating a bandwidth bottleneck at approximately 125 MB/s (1 Gbps network). A single large file download can consume the entire bandwidth, starving other operations. Fourth, without chunking, large files cannot be uploaded or downloaded in parallel — a 10 GB upload is one sequential disk write that blocks other operations.

The consistency model in the naive approach is trivially strong: there is one disk and one database, so there is no replication lag, no eventual consistency, and no split-brain scenario. A write that returns success is guaranteed to be readable immediately. This simplicity is genuinely valuable for understanding the trade-offs introduced by distributed approaches, where strong consistency requires coordination protocols like Raft consensus (v2 variant) that add latency and operational complexity.

These limitations directly motivate the distributed architectures in the v1 and v2 variants. The Metadata + Block Storage variant (v1) separates metadata from data, splits files into 64 MB blocks distributed across storage nodes, and replicates each block 3x for durability. The Erasure-Coded variant (v2) goes further with Reed-Solomon coding for storage efficiency, Raft consensus for metadata consistency, multipart uploads for large files, and lifecycle tiering for cost optimization.

This template makes the single-server limitations visible and quantifiable. Run the simulation at increasing file sizes and watch disk I/O saturate while the service layer sits idle. Compare upload throughput with the v1 variant where the same file is split into blocks uploaded in parallel across different storage nodes — the difference is dramatic. The simulation also highlights the delete non-atomicity: the disk unlink and DB delete are two separate operations, so a crash between them leaves either an orphaned file (no metadata pointing to it) or a dangling metadata row (pointing to a deleted file).

Distributed file system design appears in interviews at Google (GFS/Colossus), Amazon (S3), Meta (Tectonic), Microsoft (Azure Blob), Dropbox, and Netflix. Interviewers expect candidates to start with the single-server baseline, identify the capacity/durability/throughput limitations, and propose separation of metadata and data planes as the first architectural improvement.

The naive file system is a three-component linear architecture: Client, FileService, and FileDB (PostgreSQL). There is no load balancer, no cache, no replication, no event stream, and no separation between metadata and data planes. This is the absolute minimum viable file storage system.

All traffic flows directly from the Client to the FileService, which handles all four operations: upload, download, list, and delete. The FileService is a stateless REST API running on 2 pods with 50 threads each on AWS ECS Fargate. Service processing time is approximately 10ms, but total response time is dominated by disk I/O for file reads and writes. For a small file (under 1 MB), total upload latency is 100-300ms (disk write with fsync plus database INSERT). For large files (1 GB or more), upload can take minutes as the entire file is written sequentially to a single disk.

FileDB is a single PostgreSQL instance (RDS db.r7g.xlarge with 4 vCPU and 32 GB RAM) storing file metadata. The files table has one row per file containing the file ID, human-readable filename, size in bytes, SHA-256 checksum, local disk path, content type, and timestamps. A B-tree index on file_id supports direct lookups, and an index on filename supports prefix-based listing queries. Metadata rows are small (approximately 200 bytes each), so millions of files fit comfortably. The database is not the bottleneck in this design — disk I/O is.

The system stores file data on the FileService's local disk at computed paths (/data/{file_id}). There is no object storage (S3), no distributed storage layer, and no RAID. Files exist in exactly one copy on one physical disk. The checksum computed on upload is verified on download to detect corruption, but there is no mechanism to recover from corruption — if the only copy is damaged, the data is lost.

The upload flow follows a strict sequence: FileService first writes the file bytes to local disk with fsync to ensure durability, then computes the SHA-256 checksum over the written data, and finally INSERTs the metadata row into FileDB. If the disk write succeeds but the DB INSERT fails, an orphaned file remains on disk consuming space with no metadata pointing to it. There is no cleanup mechanism for these orphans in the naive approach — a production system would need a garbage collection sweep comparing disk contents against database records.

The download flow is equally straightforward: FileService queries FileDB for the file's metadata by primary key (O(1) B-tree lookup), reads the file from the disk path specified in the metadata row, verifies the checksum, and streams the content to the client. If the checksum does not match (indicating silent data corruption or bit rot), the download fails with an error — there is no healthy replica to fall back to.

The concrete scaling ceiling is approximately 400 mixed operations per second, limited by disk I/O bandwidth. At this point, upload and download operations compete for the same disk controller, and large file operations starve small ones. The 100-connection PostgreSQL pool is not the bottleneck at this scale — the disk is. Storage capacity is bounded at approximately 16 TB, after which the server cannot accept new uploads.

There is no redundancy at any layer. If the FileService process crashes, it restarts but loses any in-flight uploads. If the disk fails, all file data is permanently lost. If PostgreSQL fails, files on disk become inaccessible because their metadata (paths, checksums) is gone. The system has a single point of failure at every component.