Bird
Raised Fist0

Design a CI/CD Pipeline System - Build, Test, Deploy, Rollback, Artifact Registry

HLDhardInterview freq: high
Choose your preparation mode4 modes available
▶
Request Trace
Step 1/5
API Gateway (Envoy)

Receives pipeline trigger request

Accepts developer's HTTP REST call to start pipeline

Protocol:HTTP/REST
BeforeNo active pipeline for this commit
AfterPipeline trigger request forwarded to orchestrator
Pipeline Orchestrator (Argo Workflows)

Schedules build job

Creates Kubernetes pod running BuildKit to build container image

Protocol:gRPC
BeforePipeline steps not started
AfterBuild job running in Kubernetes pod
Build System (BuildKit + Kubernetes)

Builds container image

Executes Dockerfile steps, produces image artifact

Protocol:HTTPS
BeforeBuild pod initialized, source code fetched
AfterContainer image built and ready for push
Artifact Registry (Harbor)

Stores built image

Receives image push, stores with version tags

Protocol:REST API
BeforeNo new image version in registry
AfterNew image version available for deployment
Deploy Sys (Spinnaker)

Deploys new image

Fetches image from registry and updates target environment

Protocol:REST API
BeforeTarget environment running previous image version
AfterTarget environment updated with new image version
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│      API Gateway (Envoy)       │
└───────────────┬───────────────┘
                │ HTTP/REST
                ▼
┌───────────────────────────────┐
│ Pipeline Orchestrator (Argo)  │
│          Workflows            │
└───────────────┬───────────────┘
                │ gRPC
                ▼
┌───────────────────────────────┐
│      Build System (BuildKit)  │
│        + Kubernetes Pods      │
└───────────────┬───────────────┘
                │ HTTPS
                ▼
┌───────────────────────────────┐
│   Artifact Registry (Harbor)  │
└───────────────┬───────────────┘
                │ REST API
                ▼
┌───────────────────────────────┐
│      Deploy Sys (Spinnaker)   │
└───────────────────────────────┘

This CI/CD pipeline architecture uses Envoy as the API Gateway to receive developer requests and route them to Argo Workflows, the orchestrator managing the pipeline steps. Argo schedules build jobs on Kubernetes pods running BuildKit, which builds container images. Once built, images are pushed securely to Harbor, the artifact registry storing versioned images. Finally, Spinnaker pulls the new image from Harbor and deploys it to the target environment, enabling automated delivery. Each component communicates via well-defined protocols like HTTP/REST and gRPC, ensuring modularity and scalability. This vertical flow from trigger to deploy highlights clear separation of concerns and reliable artifact management.

Primary Focus

✓

Practice

(1/5)
1. A real-time ML inference system must serve predictions with minimal latency while allowing safe model updates without downtime. Which component best enables seamless model rollout with instant rollback capability?
easy
A. Shadow mode deployment that runs new models in parallel without affecting live traffic
B. A/B testing framework that splits traffic evenly between models
C. Batch inference pipeline that processes data offline and updates predictions periodically
D. Feature store that caches input features for faster model access

Solution

  1. Step 1: Identify deployment strategies for safe model updates

    Batch inference (C) is offline and adds latency, so it doesn't support real-time rollout. Feature store (D) optimizes input features but doesn't handle rollout or rollback. A/B testing (A) splits live traffic, risking user experience if the new model is faulty.
  2. Step 2: Understand shadow mode benefits

    Shadow mode (B) runs new models in parallel on live data without affecting production responses, enabling validation and instant rollback if issues arise.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Shadow mode runs new models safely alongside production [check]
Hint: Shadow mode isolates new models without impacting live traffic [OK]
Common Mistakes:
2. In the order matching flow, at step 5 the Matching Engine receives a new buy order for stock XYZ. What state does the Matching Engine hold immediately after processing this order if no matching sell orders exist?
easy
A. The order is marked as matched and removed from the order book
B. The order is added to the buy side of the order book and marked as open
C. The order is rejected due to lack of matching sell orders
D. The order is forwarded to the Market Data Feed before being stored

Solution

  1. Step 1: Trace Matching Engine behavior at step 5

    When no matching sell orders exist, the buy order is added to the order book's buy side and marked as open, waiting for future matches.
  2. Step 2: Eliminate other options

    The order is marked as matched and removed from the order book is wrong because no match occurred; The order is rejected due to lack of matching sell orders is wrong because orders are not rejected for no matches; The order is forwarded to the Market Data Feed before being stored is wrong because Market Data Feed only publishes after matching or order book update.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Unmatched order -> added to order book as open [check]
Hint: Unmatched orders stay open in order book [check]
Common Mistakes:
3. For a system requiring extremely low false negatives and exact key existence checks at scale, which approach is best?
medium
A. Use a counting Bloom filter to track exact key counts and avoid backend queries
B. Use only a Bloom filter for all key existence checks to minimize latency
C. Use a distributed cache storing all keys for exact lookups without Bloom filters
D. Combine a Bloom filter for negative filtering with a backend exact lookup for positives

Solution

  1. Step 1: Analyze false negative tolerance

    Bloom filters have zero false negatives but allow false positives, so exact checks need backend confirmation.
  2. Step 2: Evaluate approaches

    Only Bloom filter (A) risks false positives causing incorrect hits. Distributed cache (C) is costly at scale. Counting Bloom filters (D) track counts but still have false positives and complexity.
  3. Final Answer:

    Option D -> Option D
  4. Quick Check:

    Bloom filter filters negatives; backend confirms positives for exactness [check]
Hint: Bloom filter filters negatives; backend confirms positives [check]
Common Mistakes:
4. At 10x scale, which component in a content negotiation versioning system is most likely to become the bottleneck, and why?
hard
A. Backend services, because they must support multiple versions simultaneously increasing resource usage
B. API gateway, because parsing and routing based on Accept headers is CPU-intensive and cannot be cached easily
C. CDN caches, because they cannot cache responses differentiated only by headers effectively
D. Client SDKs, because they must handle multiple media types increasing complexity and errors

Solution

  1. Step 1: Identify component handling content negotiation

    The API gateway parses Accept headers to route requests to correct versioned backend.
  2. Step 2: Analyze scaling impact

    Parsing headers is CPU-intensive and cannot leverage caching well, causing gateway CPU to saturate first at high request volumes.
  3. Step 3: Compare other components

    Backends scale horizontally; CDNs struggle but can be configured; client SDKs are not server bottlenecks.
  4. Final Answer:

    Option B -> Option B
  5. Quick Check:

    Gateway CPU parsing Accept headers saturates first at scale [check]
Hint: Gateway CPU parsing Accept headers saturates first [check]
Common Mistakes:
5. At 10x scale, which component in a synchronous quorum replication system is most likely to become the bottleneck and why?
hard
A. Quorum coordinator because it must wait for majority acknowledgments synchronously
B. Storage nodes because disk I/O saturates under high write volume
C. Network links because replication traffic grows linearly with replicas
D. Client-side libraries because they block waiting for acknowledgments

Solution

  1. Step 1: Identify synchronous quorum coordinator role

    Coordinator waits synchronously for majority acks, causing latency and throughput limits.
  2. Step 2: Compare other components' scaling challenges

    Storage nodes and network scale better; client-side blocking is per client, less centralized.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Coordinator sync wait limits throughput at scale [check]
Hint: Coordinator sync wait blocks throughput first at scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard