An enterprise distributed systems design course for building reliable, secure, and operable platforms on Azure, from first principles to production AI workloads.

┌─ architecture-console ──────────────────────────────────────────────────────┐
│                                                                             │
│  $ design --for production --with azure --assume partial-failure            │
│                                                                             │
│  INPUT   product intent, traffic, data, people, regulation                  │
│  OUTPUT  a system you can explain, operate, recover, and defend             │
│                                                                             │
│  [00] primitives  [01] systems  [02] retrieval  [03] control plane          │
│  [04] serving     [05] compute  [06] lifecycle  [07] safety                 │
│  [08] operations  [09] edge     [10] case studies                           │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

[!TIP] This is a source-grounded course for engineers who need to make architecture decisions under real constraints. Complete the engineering foundation first if you cannot yet trace, debug, disassemble, structure, and review production-shaped services.

System design turns product requirements into explicit contracts for data, compute, networking, identity, capacity, recovery, and operations. This course begins with those mechanics, then applies them to Azure platforms and AI workloads where token budgets, retrieval quality, model latency, and tool authority become part of the architecture.

Author's note

./boot

Architecture is the discipline of making system behavior explicit before traffic, failure, security review, or cost forces the issue. Each lesson follows a request through its boundaries: identity, network, API, data, queue, model, operator, and recovery path.

The Azure Well-Architected Framework provides the recurring review lens: reliability, security, cost optimization, operational excellence, and performance efficiency.

git clone https://github.com/DrHazemAli/enterprise-system-design.git
cd enterprise-system-design
open foundation/README.md

./principals --level principal-distinguished

$ principals --author "Hazem Ali" --scope consequential-systems

  HAZEM'S PRINCIPALS
  Informed by enterprise engineering work and published systems research.
  Covers engineering, AI, cybersecurity, networking, mission-critical systems, and operations.

  Begin: principals/README.md

Open Hazem's Principals.

./choose-route

$ route --list

  00  BUILD ENGINEERING JUDGMENT
      Execution, debugging, disassembly, SOLID, Clean Architecture, and workload review.
      Begin: foundation/README.md

  01  BUILD THE MENTAL MODEL
      Cloud, networks, APIs, data, and LLM mechanics.
      Begin: reference/00-ground-zero/00-cloud-computing-and-azure-resource-manager.md

  02  DESIGN A RELIABLE SERVICE
      Scale, consistency, estimation, caches, queues, and backpressure.
      Begin: reference/01-system-design-foundations/06-scale-from-one-to-one-million.md

  03  DESIGN AN ENTERPRISE AI SYSTEM
      Retrieval, permission-aware data, rate limits, routing, agents, and serving.
      Begin: reference/02-data-and-retrieval/12-embeddings-and-vector-similarity.md

  04  STUDY HAZEM'S PRINCIPALS
      Contracts, invariants, authority boundaries, verification, containment, and recovery.
      Begin: principals/README.md
Route First lesson
00 Engineering foundation
01 Cloud computing and Azure Resource Manager
02 Scale from one to one million
03 Embeddings and vector similarity
04 Hazem's Principals

Hazem's Principals are organized into six disciplines. Most disciplines contain chapters 01 through 05; cybersecurity extends through 07 for auditable agent authority and inference-memory integrity:

Discipline Entry principal
Engineering Boundary-first system design
Mission-critical systems Safe state and failure containment
Cybersecurity Zero-trust AI execution
AI systems Representation, authority, and memory
Networking Packet path and forwarding evidence
Reliability and operations Consequence-oriented SLOs

./atlas --visual

Enterprise RAG evidence flow Inference request lifecycle
Evidence before generation
Trace retrieval, authorization, grounding, and response construction.
Every token has a path
Inspect admission, execution, memory, and response delivery.
Model routing and failover KV cache and continuous batching
Route for failure
Choose a model, absorb faults, and retain a governed fallback.
Serve without wasting memory
Reason about context state, scheduling, and throughput.

./map --dependency-flow

flowchart LR
  Z[Foundation<br/>Engineering judgment] --> A
    subgraph Foundations
        A[00<br/>Ground zero] --> B[01<br/>System design]
    end
    subgraph AI systems
        B --> C[02<br/>Data and retrieval]
        C --> D[03<br/>AI control plane]
        D --> E[04<br/>Inference and serving]
    end
    subgraph Production reality
        E --> F[05<br/>Execution and HPC]
        F --> G[06<br/>Model lifecycle]
        G --> H[07<br/>Security and safety]
        H --> I[08<br/>Operations]
        I --> J[09<br/>Edge and hybrid]
        J --> K[10<br/>Case studies]
    end

./curriculum --modules

ID Module Architectural question
00 Ground zero What happens between a user, a name, a request, and a resource?
01 System design foundations What must stay true as load and failure increase?
02 Data and retrieval How does knowledge become authorized, searchable evidence?
03 AI control plane Who controls tokens, tools, state, and model selection?
04 Inference and serving Where do latency, memory, batching, and quality trade?
05 Execution and HPC How do compute topology and data movement constrain the job?
06 Model lifecycle How is a model trained, evaluated, promoted, and rolled back?
07 Security and safety How are identity, data, networks, and model behavior bounded?
08 Operations and governance Can the system be observed, evaluated, changed, and audited?
09 Edge and hybrid What changes when connectivity, location, and control are distributed?
10 System design case studies Can the preceding decisions survive a complete design review?

./principals --domains

ID Principal collection Assumption to reject Governing question
P01 Engineering Component success implies system correctness. What can still go wrong when every component returns success?
P02 AI systems The same prompt and answer imply the same execution. Which machine-visible state changed while the prompt and answer still looked the same?
P03 Cybersecurity An authentic control proves that the intended object and consequence were authorized. What can a fully compromised proposer still cause without a fresh, target-bound capability?
P04 Mission-critical systems More availability and faster recovery are always safer. When evidence weakens, which authority disappears automatically?
P05 Reliability and operations Green infrastructure and successful requests imply correct outcomes. Which evidence turns apparent success into a decision to admit, quarantine, roll back, or resume?
P06 Networking One end-to-end path owns the operation. What if no single path ever carried both authority and acknowledgment: where does the operation's network causality live?

./lesson --guarantees

Every chapter leaves a design artifact behind:

  requirements + assumptions        architecture + trust boundaries
  request and recovery flows        interfaces + data ownership
  capacity and cost reasoning       failure modes + observability
  security controls + alternatives  review prompt + decision record

$ cd /github/DrHazemAli/enterprise-system-design