Object Storage Internals Explained: A Deep-Dive for System Design Interview

In the evolving world of large-scale data systems, object storage has emerged as the go-to architecture for modern workloads such as analytics, backups, and media repositories. If you're coming from a traditional file system (FS) background, the switch in concepts can be non-trivial. This post distills key internals of object storage and aligns them with file system concepts where appropriate.

What Is Object Storage?

Object storage manages data as discrete units called objects instead of files or blocks. Each object contains:

The data (blob)

A unique identifier (object key)

Rich metadata (user-defined or system-generated)

Unlike file systems that maintain a strict directory hierarchy and POSIX permissions, object storage uses a flat namespace and is accessed through APIs (e.g., REST, S3).

Key Concepts of Object Storage Internals

1. Immutability and Versioning

Objects are immutable: updates mean writing a new version.

Versioning is optional. If disabled, older versions are discarded.

FS Analogy: In FS, files are mutable, and overwrites modify data in-place.

2. Authentication & Authorization

AuthN and AuthZ are enforced via IAM, not the OS.

Policies can be defined at 3 levels:

IAM Policy (user/role level)

Bucket Policy (bucket-wide access rules)

Object ACL (per-object fine-grained permissions)

Important Rule: Access is granted only if all layers allow. An explicit deny anywhere wins.

FS Analogy: FS uses UID/GID and rwx bits. OS kernel enforces both AuthN and AuthZ.

3. No Directories or Links

There are no directories or symbolic/hard links.

Keys use / as a delimiter for logical grouping, but it's not hierarchical.

FS Analogy: Directories are inodes with filename → inode mappings and support links. Not applicable in object storage.

4. No Global Metadata Structures

No superblocks, inode tables, or block groups.

Metadata is stored with the object and indexed in internal DBs (not exposed).

FS Analogy: FS uses fixed-size inodes and metadata blocks. Object storage embeds metadata directly with the object.

5. Access Control = Explicit and Declarative

IAM policy = Who can do what across services

Bucket policy = Who can access this bucket/objects

Object ACL = Who can access this object

All must independently allow. No implicit inheritance.

6. Scalability and Consistency

Designed for massive scalability (billions of objects)

Offers eventual or strong consistency depending on the system

FS Analogy: Local FS are strongly consistent by default, but not designed for internet-scale.

7. No Garbage Collection in FS, But Needed Here

Object stores perform garbage collection for unreferenced chunks or versions.

FS Analogy: Traditional file systems don’t need GC unless part of a log-structured file system.

8. Best Use Cases

Object Storage: OLAP, backups, media delivery, logs

Block Storage (e.g., EBS): OLTP, databases, low-latency workloads

Final Thoughts

Understanding object storage internals not only helps in designing scalable systems, but also prepares you for domain-specific interviews like AWS EBS or S3. The mental shift from managing blocks and inodes to handling immutable objects and policies is key to thriving in the cloud-native era.