General

CAP, BASE, SOLID & KISS

TL;DR Master CAP theorem, BASE, SOLID principles & KISS in one deep-dive guide. Real-world examples, code snippets & expert insights for distributed systems design.

By admin 32 min read 143 views

Read this article as text (accessible version)

System Design Deep Dive

CAP, BASE, SOLID & KISS: The System Design Acronyms Every Engineer Must Master (With Real Examples)

📅 June 2025 ⏱ ~18 min read 🎯 3,400+ words By Senior DevOps Team

You've probably dropped these words in a stand-up or seen them on a whiteboard: "eventual consistency," "single responsibility," "keep it simple." But there's a difference between knowing an acronym and understanding it deeply enough to make the right architectural decision at 2 AM when your distributed database is split in half. This guide closes that gap.

CAP Theorem BASE Principles PACELC SOLID KISS Post Excerpt

CAP, PACELC, BASE, SOLID, KISS — these aren't just alphabet soup. They're the mental models that separate engineers who build systems that scale from those who rebuild the same bugs every quarter. This deep-dive guide breaks down every acronym with real-world analogies, code examples, and the nuance most tutorials skip.

Introduction

Why These Acronyms Actually Matter

Let me paint a picture. It's 11 PM. Your e-commerce platform is running a flash sale. Traffic is 40× the normal load. Suddenly, two of your ten database replicas lose connectivity to the rest of the cluster. You're staring at your monitoring dashboard and you need to make a call: do you serve stale inventory data and keep the site up, or do you return errors until the network heals? That decision — made in seconds — is the CAP theorem playing out in real time.

Most tutorials present CAP, BASE, SOLID, and KISS as a vocabulary lesson. Memorize the letters, move on. But that's like handing someone a scalpel and calling them a surgeon. These are frameworks for reasoning under constraint. They don't tell you what to do — they tell you what you're trading away when you make a choice. And in distributed systems and software architecture, everything is a trade-off.

Here's the thing most tutorials miss: these acronyms don't live in isolation. Your choice between ACID and BASE in the data layer ripples directly into how you design your service interfaces (SOLID's Interface Segregation Principle), which in turn determines whether your system stays KISS-compliant or spirals into a 47-microservice nightmare that only one person on your team understands. They're interconnected lenses on the same problem.

Let's break every one of them down — deeply, with analogies, code, and the sharp edges the textbooks quietly skip over.

CAP Theorem

The CAP Theorem — You Only Get to Pick Two

In 2000, computer scientist Eric Brewer formulated what would become one of the most debated ideas in distributed systems: in any distributed data store, you can only reliably guarantee two out of three properties — Consistency, Availability, and Partition Tolerance. Two years later, it was formally proved by Gilbert and Lynch. Two decades later, engineers are still arguing about what it really means at dinner.

Let's define the three precisely, because fuzzy definitions lead to fuzzy decisions. Consistency means every read returns the most recent write, or returns an error. There is no "maybe you'll get the old data" — every node sees the same data at the same time. Availability means every request gets a response — not an error, a response — though it might not reflect the most recent write. Partition Tolerance means the system continues operating even when network messages between nodes are lost or delayed.

Real-World Analogy

Picture a chain of ATMs during a bank's network outage. A CP system would refuse your transaction entirely — "I can't confirm your balance, so I won't let you withdraw." A AP system would let you withdraw even if it's not 100% sure you have the funds — and reconcile later. The network problem (partition) is unavoidable. You pick your poison.

Myth-Busting

Here's what most engineers get wrong: partition tolerance isn't really optional. In any distributed system running over a real network, partitions will happen. You're not choosing P or no-P — you're choosing between C and A when P occurs. So the real choice is always CA vs CP vs AP, never a pure CA system in distributed contexts. Eric Brewer himself said the theorem is "somewhat misleading" in its original form.

In practice: HBase, MongoDB in primary mode, and Zookeeper lean CP — they'd rather return an error than stale data. Cassandra and CouchDB lean AP — they'd rather give you last-known-good than nothing. Knowing which camp your database is in is table stakes before designing any distributed feature.

# Simulating a CP vs AP behavior decision in Python
class CPDatabase: 
 def read(self, key, partition_active=False): 
 if partition_active: 
 raise Exception("Partition detected: refusing stale read") 
 return self.store.get(key) # Strong consistency guaranteed
class APDatabase: 
 def read(self, key, partition_active=False): 
 # Always responds — partition or not
 return self.local_cache.get(key, "stale_or_best_known")

⚡ Pro Tips / Common Mistakes — CAP

Don't choose a database before knowing its CAP classification — it should inform the choice, not be an afterthought.
Avoid the mistake of thinking "eventual consistency = bad." For read-heavy workloads like social feeds or analytics dashboards, AP is often the right call.
CAP says nothing about latency. A CP system can still be slow even when it responds. That's where PACELC enters the picture.
Test partition behavior in staging. Most teams only discover their CP/AP trade-offs in production, which is a terrible time to learn.

PACELC Theorem

PACELC — Because CAP Forgot About Latency

The CAP theorem is brilliant, but it's also a bit like a weather forecast that only mentions rain or sunshine and ignores temperature. Professor Daniel Abadi at Yale noticed the gap in 2012 and proposed PACELC: if Partition (P) occurs, you must choose between Availability (A) and Consistency (C); Else (E) — when the system is running normally — you must choose between Latency (L) and Consistency (C).

This matters enormously in practice. A system like Amazon DynamoDB operates globally across regions with hundreds of milliseconds of network distance between them. Even when there's no partition, you still have a choice: do you wait for all replicas to confirm a write (strong consistency, higher latency) or do you acknowledge the write immediately and replicate in the background (lower latency, eventual consistency)? PACELC forces you to make this decision explicitly, not accidentally.

Real-World Analogy

Imagine a Google Doc being edited by 5 people simultaneously. When the internet cuts out (partition), you can either block all edits or allow offline edits to be reconciled later. But even with a perfect connection, you still choose: do you lock the document while one person types (consistent but slow), or let everyone type freely and merge conflicts (fast but sometimes messy)? That's the Else-Latency-Consistency trade-off.

In PACELC classification, DynamoDB is PA/EL — it prioritizes Availability during partitions and Low Latency during normal operation. Google Spanner, by contrast, is PC/EC — it holds firm on Consistency in both scenarios, using GPS-synchronized atomic clocks to achieve something that was thought impossible: global consistency without sacrificing too much latency. That engineering choice is reflected directly in Spanner's pricing.

⚡ Pro Tips / Common Mistakes — PACELC

Most workloads spend 99.9% of their time in the "Else" branch — partitions are rare. Design for low latency first, not just partition recovery.
Don't confuse PACELC classification with database capability. DynamoDB can be configured for strong consistency per-read — it's just not its default optimized mode.
When interviewing, PACELC signals deeper systems thinking than CAP alone. If you're asked about DynamoDB, mention both.

BASE Principles

BASE — The Distributed Database's Philosophy of "Good Enough, for Now"

If ACID principles are the gold standard of relational databases — Atomic, Consistent, Isolated, Durable — then BASE is what happens when you accept that the gold standard is too expensive at planetary scale. BASE stands for Basically Available, Soft State, Eventual Consistency. And before you dismiss it as "cutting corners," understand that the apps you use most — Instagram, YouTube, Amazon, Twitter — run on BASE-compliant systems. The philosophy isn't inferior; it's different.

Basically Available means the system stays responsive even when parts of it are degraded. You might get cached results, you might get a "best effort" response, but you get something. It's the distributed equivalent of a restaurant saying "the kitchen's slammed, but here's bread while you wait." Soft State is the acknowledgment that data can be in flux — different nodes may have different values for the same key at the same moment, and that's acceptable by design. Eventual Consistency is the promise: given enough time and no new updates, all replicas will converge to the same value. Not instantly. Eventually.

Real-World Analogy

Think about your Twitter/X timeline. When Elon Musk tweets something, it doesn't appear for every user on the planet at the exact same millisecond. Some users in Singapore see it 400ms before users in Brazil. This is eventual consistency. The system is basically available (you can always load your timeline), it's in soft state (different servers have different cached versions of the timeline), and eventually consistent (give it a few seconds, and everyone sees the same tweet count). The alternative — making every timeline load wait until all 300 data centers agree — would make Twitter unusable.

// BASE in action: DynamoDB write with explicit consistency config
const { DynamoDBClient, GetItemCommand } = require("@aws-sdk/client-dynamodb");
const client = new DynamoDBClient({ region: "us-east-1" });
// Eventually consistent read (default) — lower latency, BASE behavior
const eventually = await client.send(new GetItemCommand({ TableName: "Orders", Key: { orderId: { S: "ord_123" } }, ConsistentRead: false // ← BASE: might return stale data }));
// Strongly consistent read — higher cost, ACID-like behavior
const strongly = await client.send(new GetItemCommand({ TableName: "Orders", Key: { orderId: { S: "ord_123" } }, ConsistentRead: true // ← ACID-like: always latest data }));

Here's the nuance most junior engineers miss: BASE and ACID are not enemies. In a well-designed system, you'll use both — ACID for financial ledgers and payment records (where you cannot afford to show stale data), and BASE for product catalogs, social feeds, and session caches (where eventual consistency is invisible to users and saves enormous infrastructure cost). The skill is knowing which tier of your architecture gets which treatment.

⚡ Pro Tips / Common Mistakes — BASE

Never use BASE for financial transactions or inventory counts where double-spending or overselling is possible. A flash sale that sells 150 units of a 100-unit stock is a BASE misconfiguration, not a feature.
Design your application layer to tolerate eventual consistency — show "refreshing…" indicators, use optimistic UI updates, and version your reads where possible.
Eventual consistency has a bound — it's not "maybe never." Tune your replication lag and monitor it actively with CloudWatch or your equivalent.
The "S" in BASE (Soft State) is often forgotten. Your cache invalidation strategy IS your soft state management. Get it wrong and "eventual" turns into "never."

SOLID Principles

SOLID — Writing Code That Survives You (and Your Teammates)

SOLID is a different beast from the previous acronyms — it lives at the code level, not the infrastructure level. Coined by Robert C. Martin (Uncle Bob) in the early 2000s, these five principles are the closest thing software engineering has to a universal code of ethics for object-oriented design. Follow them and your code will be modular, testable, and changeable. Ignore them and you'll end up with a codebase where touching one class breaks three unrelated features — and nobody knows why.

The honest truth? In the era of functional programming, microservices, and TypeScript, SOLID applies beyond OOP. The core insight — that software should be organized so that changes are local, not viral — is timeless. Let's walk through each principle with a real example that's messier and more educational than the usual "Animal/Dog" demo.

S Single Responsibility

A class/module should have only one reason to change. One job. One master.

O Open/Closed

Open for extension, closed for modification. Add behavior without touching existing code.

L Liskov Substitution

Subtypes must be substitutable for their base types without breaking correctness.

I Interface Segregation

Many specific interfaces beat one fat interface. Don't force clients to implement what they don't use.

D Dependency Inversion

Depend on abstractions, not concrete implementations. High-level modules shouldn't know about low-level details.

The Single Responsibility Principle (SRP) sounds obvious until you look at a real codebase and find a UserService class that handles authentication, sends emails, writes audit logs, and formats user profiles for the API. That's not one responsibility — it's five. When your email provider changes, you should not be touching the same file as your authentication logic. SRP means refactoring this into AuthService, NotificationService, AuditLogger, and UserProfileFormatter. Each changes for exactly one reason.

The Open/Closed Principle (OCP) is where most engineers feel the "aha" moment. Instead of an if/else chain that grows every time you add a payment method, you define a PaymentProcessor interface and implement StripeProcessor, PaypalProcessor, and CryptoProcessor separately. Adding Venmo next month means writing a new class — not modifying the existing billing logic. No regression risk. No sleepless nights.

// BEFORE OCP — Fragile if/else chain
function processPayment(method: string, amount: number) {
 if (method === "stripe") { /* Stripe logic */ }
 else if (method === "paypal") { /* PayPal logic */ }
 // Adding Venmo means editing THIS function ← OCP violation
}
// AFTER OCP — Extensible design
interface PaymentProcessor {
 process(amount: number): Promise<Receipt>;
}
class StripeProcessor implements PaymentProcessor {
 async process(amount: number) { /* Stripe-specific logic */ }
}
class VenmoProcessor implements PaymentProcessor {
 async process(amount: number) { /* Venmo-specific logic */ }
}
// Core billing code never changes. New processors = new files only.

The Liskov Substitution Principle (LSP) trips up engineers because it's the most subtle. The famous counterexample: if you have a Bird base class with a fly() method, and you create Ostrich extends Bird, you've violated LSP — ostriches can't fly, so substituting an Ostrich wherever a Bird is expected will break the contract. The fix is to model behavior through interfaces (Flyable, Swimmable) and compose them, rather than assuming inheritance always preserves behavior.

The Interface Segregation Principle (ISP) and Dependency Inversion Principle (DIP) are where SOLID really starts paying off at scale. ISP says don't force a robot worker class to implement an eat() method just because your worker interface has one. Split IWorker into IWorkable and IFeedable. DIP says your high-level OrderService shouldn't import MySQLOrderRepository directly — it should depend on an IOrderRepository interface. This is why dependency injection frameworks exist and why they're worth the learning curve.

⚡ Pro Tips / Common Mistakes — SOLID

Over-applying SOLID to tiny scripts or utilities is engineering theater. A 30-line CLI tool doesn't need a IFileWriter abstraction. Context matters.
SRP is the most violated principle in the wild. If you can't name a class's responsibility in five words or fewer, it probably has too many.
DIP without a DI container can lead to "constructor injection hell" — constructors with 12 parameters. Learn dependency injection frameworks (Spring, NestJS, .NET DI) alongside the principle.
LSP violations are often caught only by integration tests. Make sure your test suite tests substitution behavior, not just individual methods.

KISS Principle

KISS — The Principle That Costs Nothing and Saves Everything

KISS — Keep It Simple, Stupid — was originally a design principle from the U.S. Navy in 1960, attributed to engineer Kelly Johnson who designed the U-2 spy plane. The idea was that jet aircraft should be repairable in combat conditions by an average mechanic with basic tools. Complexity was literally a survival risk. In software, complexity doesn't get people shot, but it has killed companies, products, and careers. The principle translates with surprising precision.

Here's the counterintuitive insight that most senior engineers will confirm: simple systems are harder to design than complex ones. Adding complexity is easy — every new abstraction, every configuration flag, every plugin architecture feels like you're solving a problem. Removing it requires the conviction that the added cognitive load isn't worth the marginal benefit. Jeff Bezos famously evaluated Amazon's services partly by asking whether they could be explained on a napkin. If not, they were probably too complex.

Real-World Analogy

Google's homepage is the most visited page in human history, and it has three things: a logo, a search box, and two buttons. Competitors have tried to outdesign it with news feeds, weather widgets, trending topics, and stock tickers. They all underperformed. The KISS principle isn't about being lazy — it's about having the discipline to cut everything that doesn't serve the primary user goal. Google's simplicity is maintained by active resistance to complexity, not passive neglect.

# KISS violation: Over-engineered config loading
class ConfigurationStrategyFactory: 
 def create_loader(self, env): 
 if env === "prod": 
 return ProductionConfigurationLoaderStrategy() 
 return DevelopmentConfigurationLoaderStrategy() 
# KISS-compliant: Does the same job in 3 lines
import os
import json
config = json.load(open(f"config.{os.getenv('ENV', 'dev')}.json"))

KISS has a natural tension with SOLID. SOLID encourages you to create abstractions and separate concerns; KISS tells you not to introduce abstractions until you need them. The resolution is the "Rule of Three" — don't abstract until you see the same pattern at least three times. Your first implementation is specific. Your second is a copy-paste candidate. Your third earns the abstraction.

Common Misconception

KISS does not mean "write dumb code." A well-designed recursive algorithm is simple in the KISS sense — it's elegant and clear in expressing its intent. A 200-line imperative loop doing the same thing is complex even though it uses no advanced patterns. Simplicity is measured in cognitive load, not in sophistication of technique.

⚡ Pro Tips / Common Mistakes — KISS

The biggest KISS violation in modern engineering is premature microservices. Splitting a small app into 12 services before you understand the domain is the opposite of simple.
KISS applies to APIs too. An endpoint with 23 optional query parameters is complex. Design for the 80% use case, then add optional complexity progressively.
Simple != Simplistic. A well-tested, 50-line function that solves a hard problem is KISSing perfectly. A 200-line mess of edge-case handling is not, even without any abstractions.
Schedule regular "complexity audits." Every six months, ask: which parts of this system would take a new engineer more than a day to understand? Those are KISS candidates for refactoring.

Synthesis

How It All Connects — The Mental Map

At this point you might be wondering: what does SOLID's Dependency Inversion Principle have to do with the CAP theorem? More than you'd think. Let's trace a real system design decision from infrastructure to code level to see how these principles cascade.

Imagine you're designing a ride-sharing application — millions of location updates per second, global user base, price-sensitive infrastructure budget. At the infrastructure layer, you're making CAP decisions: your location database is AP (Cassandra or DynamoDB) because showing a driver as being 50 meters "off" for half a second is acceptable, but being unavailable during a partition is not. Your payment database is CP (CockroachDB or a strongly consistent PostgreSQL with replication) because double-charging a user is unacceptable.

Once you've chosen your databases, PACELC dictates your latency strategy. For the location service, you optimize for low latency in the normal case (PA/EL) — drivers update their position every second, and your UI can tolerate 300ms of eventual convergence. For the fare service, you accept the latency cost of consistency (PC/EC) — nobody sees their final fare until every replica agrees.

Your application then implements BASE semantics for the ride-matching service (soft state: matches may not be globally consistent for 200ms), while using ACID transactions for the payment processing pipeline. Both live in the same codebase.

Now, SOLID enters. Your RideMatchingService (S — single responsibility) talks to ILocationRepository, not directly to Cassandra (D — dependency inversion). When you eventually swap Cassandra for ScyllaDB for cost reasons, you implement ScyllaLocationRepository without touching the matching logic (O — open/closed). Your notification system implements INotifiable, not a fat IRideService interface that would force it to know about fare calculations (I — interface segregation).

And threading through all of this is KISS: every abstraction you created above is justified because the complexity is inevitable in a real ride-share system. But your internal analytics dashboard? That doesn't need an event-sourced CQRS architecture with 14 microservices. A simple read replica and a few SQL queries is KISS-compliant and correct.

"Simplicity is the ultimate sophistication." — attributed to Leonardo da Vinci, fully adopted by every engineering team that's maintained a 10-year-old codebase.

Getting Started

Getting Started — Applying These Principles Today

Theory is great; practice is where it compounds. Here's a step-by-step approach to audit your current system and apply these principles immediately — no greenfield rewrite required.

Step 1: Map your data stores to their CAP classification. List every database or data store your application uses. For each one, look up its CAP/PACELC category (the database's official documentation usually states this). Then cross-reference it with your use case. Is your CP database being used for a workload that would actually be fine with AP? If so, you're over-paying for consistency you don't need.

# Quick consistency check — run against your replica lag metric
# in AWS DynamoDB via CLI
aws dynamodb describe-table \
 --table-name YourTableName \
 --query "Table.{ReplicaCount:Replicas|length(@), BillingMode:BillingModeSummary.BillingMode}"
# Check replication lag in PostgreSQL read replica
SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;

Step 2: Audit one service for SOLID violations. Pick the most-changed file in your codebase from the last 90 days (your Git log will tell you). Count how many different types of reasons that file was changed. If it's more than one — logging, business logic, API formatting, error handling — you've found an SRP violation. Refactor it first. It will have the highest return on investment.

Step 3: Apply the KISS test to your newest feature. For whatever you shipped last sprint: could you explain how it works to a smart non-engineer in under two minutes? If not, document the complexity and schedule a simplification review. Complexity that can't be explained is complexity that can't be debugged.

Step 4: Design your next BASE-appropriate feature explicitly. When building social feeds, notifications, or analytics — explicitly choose eventual consistency. Write a comment in the code stating: "This read is eventually consistent by design. Staleness tolerance: <30 seconds." Make the trade-off visible and intentional, not accidental.

Step 5: Add a DIP layer before your next integration. Before you write code that calls a third-party API (payment, email, SMS), define an interface first. Then implement it. When the vendor changes (and they will), you'll thank yourself.

FAQ

Frequently Asked Questions

What's the difference between CAP theorem and PACELC? CAP describes the trade-off that occurs during a network partition: you can have consistency or availability, but not both. PACELC extends this by addressing what happens when there's no partition — the trade-off between latency and consistency. PACELC is a superset of CAP and gives a more complete picture of real-world distributed system behavior. Can a database be both ACID and BASE? Not simultaneously for the same operation, but many modern databases offer configurable consistency levels. Amazon DynamoDB, for instance, allows you to choose between eventually consistent and strongly consistent reads per query. This means a single database can operate in BASE mode for most reads (high throughput, low latency) and in ACID-like mode for critical operations (payment confirmations, etc.). Is SOLID relevant for functional programming or only OOP? SOLID was formulated with OOP in mind, but its underlying ideas apply universally. SRP maps to "a function should do one thing." OCP maps to higher-order functions and composition. DIP maps to passing dependencies as function arguments rather than importing concrete implementations. The principles are architecture-agnostic; the vocabulary is OOP-flavored. When should you NOT use eventual consistency (BASE)? Avoid eventual consistency for financial ledgers (double-spend risk), inventory reservation in high-demand scenarios (overselling risk), access control and permissions (security risk), and any two-phase operations where a partial state is dangerous. The test: "What happens if a user sees 200ms-stale data?" If the answer is "potentially harmful," use strong consistency. How does KISS principle conflict with SOLID, and how do you balance them? They conflict primarily around abstraction. SOLID encourages adding abstractions (interfaces, DI, segregated responsibilities); KISS discourages premature abstraction. The resolution is timing: apply KISS by default when building the first version, apply SOLID when you hit the pain points that SOLID is designed to solve (coupling, rigid change propagation, untestable code). The "Rule of Three" — abstract when you see the same pattern three times — is a practical heuristic for balancing both. What are the most common CAP theorem mistakes in real-world systems? The top three: (1) Choosing an AP database but writing application code that assumes strong consistency — reading immediately after writing and expecting to see the write. (2) Ignoring partition tolerance entirely, then being surprised when network issues bring down the whole system. (3) Treating CAP as binary when the reality is a spectrum — tunable consistency databases give you a dial, not a switch. Is "YAGNI" related to KISS, and which should I follow? YAGNI (You Aren't Gonna Need It) is the XP/Agile manifestation of KISS applied specifically to features and functionality. KISS is about design simplicity; YAGNI is about feature restraint. They're complementary: KISS governs how you build what you're building, YAGNI governs whether you build it at all. Follow both, and you'll spend less time maintaining complexity that was never needed. Which of these principles matters most for a system design interview? For infrastructure-level questions (design Twitter, design Uber), CAP and PACELC signal the deepest understanding — they show you know why you're choosing a particular database, not just what it is. For code-level design questions, SOLID demonstrates architectural maturity. Mentioning KISS in any context earns credibility because it shows you value long-term maintainability over short-term cleverness. Conclusion

The Bottom Line

CAP, PACELC, BASE, SOLID, KISS — these aren't just vocabulary for impressing interviewers. They're compressed wisdom from decades of engineers building systems that broke in fascinating and expensive ways, learning why, and crystallizing those lessons into frameworks you can apply before making the same mistakes.

The most important thing to internalize is that these principles are about making trade-offs explicit. Every distributed system violates CAP's C or A during a partition — the question is whether that violation is intentional or accidental. Every codebase makes abstraction decisions — the question is whether they're SOLID or spaghetti. Every product has complexity — the question is whether it's earned or accumulated by neglect.

You don't need to apply all of these simultaneously and perfectly. Start with the one that addresses your most painful current problem. Is your codebase breaking whenever someone touches a shared class? Start with SRP. Is your database the wrong fit for your consistency requirements? Start with CAP. Is your system increasingly difficult to explain to new engineers? Start with KISS.

The engineers who build systems that last — not just systems that work — are the ones who treat these frameworks as living tools, not one-time lessons. Pull them out when you're making a decision. Reference them in code reviews. Use them to articulate trade-offs to non-technical stakeholders. That's what mastery looks like.

CAP, BASE, SOLID & KISS: The System Design Acronyms Every Engineer Must Master (With Real Examples)

Why These Acronyms Actually Matter

The CAP Theorem — You Only Get to Pick Two

PACELC — Because CAP Forgot About Latency

BASE — The Distributed Database's Philosophy of "Good Enough, for Now"

SOLID — Writing Code That Survives You (and Your Teammates)

KISS — The Principle That Costs Nothing and Saves Everything

How It All Connects — The Mental Map

Getting Started — Applying These Principles Today

Frequently Asked Questions

The Bottom Line

Related articles

How Microchips Are Made: The Complete CPU Fabrication Process Step by Step | Zetsapp

How Hard Disk Drives Work: Inside the Spinning Metal That Still Stores Most of the Internet | Zetsapp

How GPUs Actually Work: The Nvidia GA102 Architecture Decoded Inside the RTX 3090