Who is the author of this book?

Ayoub Zulfiqar is the sole author. He is a Systems Architect and Security Researcher with 8+ years of experience in systems architecture, offensive security research, and open-source software.

What topics does this book cover?

The book covers sixteen chapters in four parts plus three reference appendices: Low-Level Systems and CS Engineering; Software Architecture, Languages, and System Design; Cloud Native, Infrastructure, and Network Engineering; and AI Infrastructure, Security, and High Availability. Topics include cache hierarchies, kernel mechanics, data structures, concurrency, language runtimes, database internals, distributed consensus, Kubernetes internals, machine learning infrastructure, zero trust security, and scalability.

Is this book suitable for beginners?

The book assumes you write code in at least one systems or managed language and have deployed something that broke. It does not assume a formal computer science degree. Every technical term is defined at first use.

What writing style does the book use?

The book uses Simplified Technical English (ASD-STE100), the controlled language adopted by aerospace since 1983. Sentences are under 25 words, the voice is active, and one word carries one meaning across the entire text.

Systems EngineeringREV 1.016 chapters and 3 appendices~5 hrs read

Computer Science: From First Principles to Production Scale

Name: Computer Science: From First Principles to Production Scale
Author: Ayoub Zulfiqar

A Systems Engineering Handbook

Cache lines to consensus. Kernels to Kubernetes. Transistors to trillion-parameter inference.

A systems engineering handbook spanning sixteen chapters across four parts: low-level systems, architecture and data, cloud native, and AI, security, and scale. Written in Simplified Technical English for precision under pressure.

Ayoub Zulfiqar

Systems Architect & Security Researcher. Sole author.

Written in Simplified Technical English (ASD-STE100). Revision 1.0, September 2026. Free to read online.

Start reading: Chapter 1 Table of Contents

Preface

A senior engineer and a junior engineer look at the same latency graph. The junior engineer sees a line that goes up. The senior engineer sees a queue that crossed its service rate, a garbage collector that paused a thread, or a NUMA node that ran out of local memory. The difference between them is not intelligence. The difference is a mental model that reaches from the application down to the hardware and out to the network.

This book builds that model.

What the book covers

The book runs from the cache line to the multi-region system. Part I fixes the physical constants: memory hierarchy, instruction sets, kernel mechanics, data structures under real memory behavior, and concurrency on real cores. Part II builds the software layer: language runtimes and their memory models, design boundaries that survive a network, storage engine internals, and distributed consensus. Part III covers the production substrate: high-performance networking, container isolation, service meshes, and stream processing. Part IV puts the stack under load: AI inference infrastructure, observability, zero trust security, and case studies at one million requests per second.

Each chapter ends where the next one begins. Chapter 3 spends the cache numbers that Chapter 1 fixes. Chapter 7 spends the storage numbers that Chapter 2 fixes. Chapter 16 spends all of them.

What the book assumes

The book assumes that you write code in at least one systems language or one managed language. It assumes that you deployed something and watched it break. It does not assume a formal computer science degree, and it defines every term that it uses.

The book does not teach a programming language. It does not teach Kubernetes commands. It teaches the mechanism under the command, because the commands change every eighteen months and the mechanism does not.

How to read it

Read Part I in order. The numbers in Chapter 1 appear in every later chapter, and the chapter is short. After Part I, the parts are close to independent. An engineer who owns a database can go straight to Chapter 7. An engineer who owns an inference cluster can go straight to Chapter 13, though Chapter 4 and Chapter 9 carry the parallelism and the network model that Chapter 13 assumes.

Four block types repeat through the book:

A note block adds a fact that the main argument does not need.
A warning block names a failure that costs money or data.
A production block gives a rule that holds in a real deployment.
A key numbers block gives the measurements for the section.

Each chapter ends with a summary block. The summary is a set of claims, not a set of topics. If you disagree with a claim in the summary, the chapter body holds the argument.

A note on numbers

This book gives numbers. Numbers age. A 2026 NVMe drive reads a 4 KiB block in about 80 microseconds, and a 2030 drive will read it faster. The number will change. The ratios will not change. A drive stays roughly one thousand times slower than DRAM and roughly one hundred thousand times slower than L1 cache, because those ratios follow from physics and from economics rather than from a product cycle.

Read the numbers for their ratios. Design against the ratios. Measure the absolutes on your own hardware, because your hardware is the only hardware that runs your code.

On the writing

The book uses a controlled subset of English. Sentences stay under 25 words. The voice stays active. The modal verbs are can, will, and must. There are no contractions and no em-dashes. One word carries one meaning across the whole text.

This style is deliberate. A controlled language removes the second reading. An engineer who reads a runbook at 03:00 during an incident cannot afford a sentence that parses two ways. The same discipline applies to a book about systems, because the subject is already hard enough.

16 chapters and 3 appendices, grouped in 5 parts. Each chapter is its own page.

Part I

Low-Level Systems and CS Engineering

Every abstraction above this layer inherits its physics. A cache miss costs about 80 nanoseconds. A context switch costs a few microseconds. A page fault that reaches an NVMe drive costs 80,000 nanoseconds. These four chapters fix the constants that the rest of the book spends.

Chapter 1Low-Level Systems and Computer Architecture
A program is a request. The hardware decides what that request costs. This chapter fixes the constants that the rest of the book spends: cache line size, miss latency, NUMA distance, vector width, and the price of a branch that the processor predicts wrong.
Chapter 2Operating Systems Engineering and Kernel Mechanics
The kernel is the only program that can talk to the hardware. Every read, every write, every thread wake-up crosses a boundary that costs real time. This chapter measures that boundary and shows the three ways that modern systems avoid paying it.
Chapter 3Data Structures, Algorithms, and Computational Complexity
Big-O counts operations. Hardware charges for cache misses. This chapter reconciles the two, then works through the structures that production systems actually use: hash tables that probe with SIMD, filters that answer in 10 bits per key, and spatial indexes that serve a nearest-neighbor query in a microsecond.
Chapter 4Concurrency, Parallelism, and Systems Performance
Adding cores does not add throughput. Coordination between cores costs cache line transfers, and the cost grows with the square of the core count. This chapter covers memory models, atomics, lock-free structures, async runtimes, and the queueing theory that predicts where a system stops scaling.

Part II

Software Architecture, Languages, and System Design

A running program is a memory model plus a set of boundaries. These four chapters describe how language runtimes manage memory, how design boundaries survive contact with a network, how storage engines hold durable state, and what a group of machines can agree on.

Chapter 5Programming Language Pragmatics and Memory Models
A language runtime is a set of decisions about memory, dispatch, and compilation. Those decisions set the floor on latency, the shape of the tail, and the cost of a start-up. This chapter opens the runtime and measures what each decision costs.
Chapter 6Software Design Patterns and Domain-Driven Design
A boundary in code is cheap to move. A boundary across a network is not. This chapter covers the design principles that survive the move from a function call to a remote call, and the domain modeling techniques that decide where the boundary belongs.
Chapter 7Database Internals and Storage Engine Mechanics
A database is a program that makes a promise about data that survives a power cut. This chapter opens the two storage engine families, prices the write-ahead log, defines the isolation levels by the anomalies that each one allows, and shows why MVCC turned readers and writers into strangers.
Chapter 8Distributed Systems Foundations and Consensus Protocols
A network turns a function call into a message that can arrive late, arrive twice, or never arrive, with no way to tell those cases apart. This chapter covers what a group of machines can agree on, what it costs in round trips, and which consistency model actually matches a product requirement.

Part III

Cloud Native, Infrastructure, and Network Engineering

Production is a network of isolated processes that must find each other, authenticate, and degrade without cascading. These four chapters cover the wire protocols, the isolation primitives, the traffic control plane, and the event log that carries state between services.

Chapter 9High-Performance Networking and Protocols
Every remote call pays for a handshake, a congestion window, a kernel copy, and a serialization. This chapter prices each of them, then covers TLS 1.3, QUIC, gRPC, and the three ways to leave the kernel network stack behind.
Chapter 10Containerization and Cloud-Native Runtime Internals
A container is a normal Linux process with a restricted view of the system. This chapter takes apart the namespaces, the control groups, the image layers, and the container network interface, and it prices the isolation that each one gives.
Chapter 11Enterprise Microservices and Mesh Architectures
Once a system has fifty services, every one of them needs mutual TLS, retries, timeouts, and telemetry. A service mesh moves that code out of the application and into the network. This chapter covers the Envoy datapath, the sidecar and ambient models, and the resilience patterns that stop one slow service from taking down the rest.
Chapter 12Stream Processing and Real-Time Event Infrastructures
An append-only log is the simplest durable data structure and the most useful one for connecting services. This chapter covers Kafka internals, the three delivery semantics and what each one really costs, event-time windowing with watermarks, and the checkpoint protocol that makes exactly-once processing possible.

Part IV

AI Infrastructure, Security, and High Availability

The last four chapters put the whole stack under load. Accelerator memory management, telemetry that survives a million requests per second, a trust model with no perimeter, and a set of case studies that connect every earlier chapter to a production decision.

Chapter 13Machine Learning Engineering and AI Systems at Scale
Serving a large language model is a memory bandwidth problem wearing a compute costume. This chapter derives the arithmetic, sizes the key and value cache, explains why prefill and decode are two different workloads, and prices every form of parallelism by the communication it needs.
Chapter 14System Observability, Telemetry, and Site Reliability
A monitored system tells you that it broke. An observable system tells you why, for a failure that nobody predicted. This chapter covers the four signals, the statistics that make percentiles honest, and the error budget arithmetic that decides when a page is justified.
Chapter 15Systems Security, Cryptography, and Zero Trust
Security is a property of a whole system and not a feature that a library provides. This chapter covers the primitives and what each one is for, workload identity that replaces long-lived secrets, the post-quantum migration, and the memory safety problem that accounts for most of the vulnerabilities in systems code.
Chapter 16Scalability Trade-Offs and Case Studies
This chapter spends every number that the preceding fifteen established. Four case studies work through a system at one million requests per second, a database sharded across regions, a schema migration with no downtime, and the failure mode that recovers only when you remove the load.

Part V

Reference

Three appendices for the desk rather than the armchair. The consolidated number tables from every chapter, a glossary that defines each term once, and the diagnostic commands that turn a symptom into a measurement.

Appendix AReference Tables
Every number in this book, gathered in one place. Treat the ratios as durable and the absolutes as approximate for 2026 hardware.
Appendix BGlossary
Every term that this book defines at first use, gathered alphabetically with the chapter that introduces it.
Appendix CThe Diagnostic Toolkit
A symptom, the measurement that identifies its cause, and the command that takes the measurement. Run the command before you form the hypothesis.

About this edition

About this book

This book covers computer science fundamentals and the production architecture that rests on them. It starts at the cache line and ends at a multi-region system that serves more than one million requests per second. Sixteen chapters run in a single line of argument. Each chapter assumes the chapters before it.

The book is written for engineers who already write code and who now must answer for the behavior of a system under load. It gives numbers, names the trade-offs, and states the failure mode for each design.

Language and style

The prose follows the discipline of ASD-STE100 Simplified Technical English, the controlled language that aerospace adopted in 1983. Sentences are short. The voice is active. One word carries one meaning for the whole book. Technical terms carry a definition at first use. The goal is a text that a tired engineer at 03:00 cannot misread.

No tool and no publisher can guarantee ASD-STE100 compliance, because ASD certifies no tool. The official standard is a free download at asd-ste100.org. This book applies the spirit of the standard to a domain that the standard does not cover.

Numbers and currency

Latency numbers, throughput numbers, and hardware specifications carry a date or a source in the text. Hardware moves. A number from 2026 will drift. The ratios between numbers move much more slowly than the numbers themselves, and the ratios are the part that governs design. Read the tables as orders of magnitude, not as benchmarks.

Where a claim depends on a specific software version, the text names the version. Where a claim is a general property of a design, the text says so.

Code

Code samples are illustrative. They compile in spirit and not always in fact. Several samples remove error handling to keep the mechanism visible. Any sample that you take to production needs error handling, bounds checks, and a test.

Production notice

Do not copy a configuration from this book into a production system without a test. The book describes mechanisms and trade-offs. It does not know your workload, your hardware, or your failure budget.

Colophon

Set in Bitstream Charter for the body text, Noto Sans for headings and tables, and Fira Code for program text. Composed in Markdown, rendered to HTML, and printed to PDF with WeasyPrint.

Questions about this book

Who is the author of this book?: Ayoub Zulfiqar is the sole author. He is a Systems Architect and Security Researcher with 8+ years of experience in systems architecture, offensive security research, and open-source software.
What topics does this book cover?: The book covers sixteen chapters in four parts plus three reference appendices: Low-Level Systems and CS Engineering; Software Architecture, Languages, and System Design; Cloud Native, Infrastructure, and Network Engineering; and AI Infrastructure, Security, and High Availability. Topics include cache hierarchies, kernel mechanics, data structures, concurrency, language runtimes, database internals, distributed consensus, Kubernetes internals, machine learning infrastructure, zero trust security, and scalability.
Is this book suitable for beginners?: The book assumes you write code in at least one systems or managed language and have deployed something that broke. It does not assume a formal computer science degree. Every technical term is defined at first use.
What writing style does the book use?: The book uses Simplified Technical English (ASD-STE100), the controlled language adopted by aerospace since 1983. Sentences are under 25 words, the voice is active, and one word carries one meaning across the entire text.

Attribution and sole author credit: Ayoub Zulfiqar. All content in this book is the original work of the author.