Bird
Raised Fist0
Microservicessystem_design~25 mins

Linkerd overview in Microservices - System Design Exercise

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Design: Linkerd Service Mesh
Design the core components and flow of Linkerd as a service mesh for microservices communication. Out of scope: deep Kubernetes internals, alternative service meshes.
Functional Requirements
FR1: Provide secure communication between microservices
FR2: Enable observability with metrics and tracing
FR3: Support load balancing and failure handling
FR4: Allow easy deployment without changing application code
FR5: Integrate with existing Kubernetes clusters
Non-Functional Requirements
NFR1: Must handle up to 10,000 microservice instances
NFR2: Latency overhead should be less than 5ms per request
NFR3: Availability target of 99.9% uptime
NFR4: Support TLS encryption for all service-to-service traffic
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
Key Components
Data plane proxies (sidecars)
Control plane components
Service discovery integration
Metrics and tracing collectors
Certificate management for TLS
Design Patterns
Sidecar proxy pattern
Mutual TLS for secure communication
Circuit breaker and retry patterns
Service discovery and load balancing
Observability with telemetry data collection
Reference Architecture
                +---------------------+
                |   Control Plane      |
                |  - Service Profile   |
                |  - Identity Mgmt     |
                |  - Metrics Server    |
                +----------+----------+
                           |
                           |
        +------------------+------------------+
        |                                     |
+-------v-------+                     +-------v-------+
| Sidecar Proxy |                     | Sidecar Proxy |
| (Data Plane)  |                     | (Data Plane)  |
+-------+-------+                     +-------+-------+
        |                                     |
        |                                     |
   +----v----+                         +----v----+
   | Service |                         | Service |
   +---------+                         +---------+
Components
Control Plane
Go, Kubernetes CRDs
Manages configuration, service profiles, identity, and metrics aggregation
Data Plane Proxy (Sidecar)
Rust-based lightweight proxy
Intercepts and manages all inbound and outbound traffic for a microservice
Service Discovery
Kubernetes API
Discovers available service instances dynamically
Identity and TLS Management
mTLS with automatic certificate issuance
Ensures secure encrypted communication between services
Metrics and Tracing
Prometheus, Jaeger integration
Collects telemetry data for observability and debugging
Request Flow
1. 1. Control Plane configures sidecar proxies with service profiles and identity certificates.
2. 2. Sidecar proxies intercept all network traffic from their microservice.
3. 3. For outbound requests, proxy performs service discovery to find target instances.
4. 4. Proxy establishes mutual TLS connection to target proxy for secure communication.
5. 5. Proxy applies load balancing, retries, and circuit breaking policies.
6. 6. Metrics and tracing data are collected and sent to the control plane or external systems.
7. 7. Control Plane updates proxies dynamically as services scale or change.
Database Schema
Not applicable; Linkerd uses Kubernetes API and in-memory state for configuration and identity management.
Scaling Discussion
Bottlenecks
Control Plane overload with large number of proxies
Latency increase due to proxy processing overhead
Certificate issuance delays at scale
Metrics collection causing network or storage strain
Solutions
Horizontal scaling of control plane components with leader election
Use lightweight Rust proxies optimized for low latency
Implement certificate caching and renewal strategies
Aggregate metrics at proxies before sending to reduce volume
Interview Tips
Time: Spend 10 minutes explaining the problem and requirements, 15 minutes on architecture and components, 10 minutes on data flow and scaling, 10 minutes on Q&A.
Explain the sidecar proxy pattern and its benefits
Describe how mTLS secures service communication
Highlight observability features and their importance
Discuss how Linkerd integrates with Kubernetes service discovery
Address scaling challenges and practical solutions

Practice

(1/5)
1. What is the primary purpose of Linkerd in a microservices architecture?
easy
A. To write business logic for microservices
B. To replace the database layer in microservices
C. To help microservices communicate securely and reliably
D. To serve as a frontend framework for microservices

Solution

  1. Step 1: Understand Linkerd's role

    Linkerd is a service mesh designed to manage communication between microservices.

  2. Step 2: Identify its main function

    It ensures secure and reliable communication without changing service code.

  3. Final Answer:

    To help microservices communicate securely and reliably -> Option C

  4. Quick Check:

    Linkerd = Secure, reliable microservice communication [OK]
Hint: Linkerd manages communication, not business logic or UI [OK]
Common Mistakes:
  • Confusing Linkerd with database or frontend tools
  • Thinking Linkerd writes application code
  • Assuming Linkerd replaces microservices
2. Which of the following commands is used to check the health of Linkerd after installation?
easy
A. linkerd check
B. linkerd install
C. linkerd monitor
D. linkerd deploy

Solution

  1. Step 1: Recall Linkerd CLI commands

    Linkerd provides commands like install, check, and monitor for managing the service mesh.

  2. Step 2: Identify the health check command

    The linkerd check command verifies if Linkerd is installed and running correctly.

  3. Final Answer:

    linkerd check -> Option A

  4. Quick Check:

    Health check = linkerd check [OK]
Hint: Use 'linkerd check' to verify installation health [OK]
Common Mistakes:
  • Using 'linkerd install' to check health
  • Confusing 'linkerd monitor' with health check
  • Assuming 'linkerd deploy' is a valid command
3. Given the following snippet, what will linkerd check report if Linkerd proxies are not injected into the services? 
kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
service-a-12345           1/1     Running   0          10m
service-b-67890           1/1     Running   0          10m
medium
A. Info: Services are running but no Linkerd installed
B. All checks pass, Linkerd is fully operational
C. Error: Kubernetes cluster not reachable
D. Warning: No proxies detected, Linkerd not fully enabled

Solution

  1. Step 1: Understand proxy injection role

    Linkerd requires proxies injected into pods to manage traffic and security.

  2. Step 2: Analyze pod readiness and proxy presence

    Pods show 1/1 ready, but no proxy sidecar means Linkerd features are not active.

  3. Final Answer:

    Warning: No proxies detected, Linkerd not fully enabled -> Option D

  4. Quick Check:

    No proxies = Warning from linkerd check [OK]
Hint: No proxies means Linkerd features inactive, expect warnings [OK]
Common Mistakes:
  • Assuming pods ready means Linkerd is fully working
  • Confusing cluster reachability errors with proxy injection
  • Thinking Linkerd works without proxies
4. You deployed Linkerd but notice that traffic is not being routed through the proxies. Which of the following is the most likely cause?
medium
A. Proxies were not injected into the service pods
B. The services are not exposing any ports
C. The Kubernetes cluster is down
D. The Linkerd control plane is not installed

Solution

  1. Step 1: Check Linkerd traffic routing requirements

    Traffic routing requires proxies injected into pods to intercept and manage requests.

  2. Step 2: Identify common deployment mistakes

    If proxies are missing, traffic bypasses Linkerd, causing routing issues.

  3. Final Answer:

    Proxies were not injected into the service pods -> Option A

  4. Quick Check:

    Missing proxies = traffic not routed [OK]
Hint: Missing proxies cause traffic routing failure [OK]
Common Mistakes:
  • Assuming control plane absence causes routing issues
  • Blaming Kubernetes cluster status without checking proxies
  • Ignoring service port exposure as a cause
5. You want to add observability to your microservices using Linkerd. Which combination of features does Linkerd provide to achieve this without changing your service code?
hard
A. Database management, caching, and load balancing
B. Traffic routing, security, and built-in monitoring dashboards
C. Frontend UI components, API gateways, and authentication
D. Code instrumentation, manual tracing, and custom logging

Solution

  1. Step 1: Identify Linkerd's observability features

    Linkerd provides traffic routing, security, and monitoring dashboards automatically via proxies.

  2. Step 2: Exclude unrelated features

    Database, frontend UI, and manual code changes are outside Linkerd's scope.

  3. Final Answer:

    Traffic routing, security, and built-in monitoring dashboards -> Option B

  4. Quick Check:

    Linkerd = routing + security + monitoring [OK]
Hint: Linkerd adds observability without code changes [OK]
Common Mistakes:
  • Confusing Linkerd with database or frontend tools
  • Thinking manual code changes are needed for observability
  • Mixing Linkerd with unrelated infrastructure components