Namespace isolation in Microservices - System Design Exercise

Design: Namespace Isolation in Microservices

Design the namespace isolation mechanism for microservices deployment and management. Out of scope: detailed microservice implementation, CI/CD pipelines, or cloud provider specifics.

Functional Requirements

FR1: Isolate microservices environments to prevent interference

FR2: Allow multiple teams to deploy services independently

FR3: Support separate configurations and resource limits per namespace

FR4: Enable secure access control scoped to namespaces

FR5: Provide monitoring and logging per namespace

FR6: Allow easy creation and deletion of namespaces

Non-Functional Requirements

NFR1: Support up to 100 namespaces concurrently

NFR2: API response latency under 200ms for namespace operations

NFR3: Availability target of 99.9% uptime

NFR4: Namespaces must not share data or configurations unless explicitly allowed

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Namespace manager service

Authentication and authorization system

Configuration management per namespace

Resource quota and limit enforcement

Service discovery scoped by namespace

Logging and monitoring aggregation per namespace

Design Patterns

Multi-tenancy isolation

Role-based access control (RBAC)

Sidecar pattern for namespace-specific proxies

Namespace-scoped service mesh

Resource quota and limit pattern

Reference Architecture

Client
  |
  v
API Gateway (validates user, routes by namespace)
  |
Namespace Manager Service --- Auth Service (RBAC)
  |
+-----------------------------+
| Namespace Isolation Layer    |
| +-------------------------+ |
| | Config Store (per NS)    | |
| | Resource Quota Manager   | |
| | Service Discovery (NS)   | |
| +-------------------------+ |
+-----------------------------+
  |
Microservices Cluster (pods/services isolated by namespace)
  |
Monitoring & Logging (aggregated per namespace)

Components

API Gateway

Nginx / Envoy

Routes requests to services based on namespace and validates authentication

Namespace Manager Service

Custom microservice (Node.js/Go)

Manages lifecycle of namespaces, enforces isolation policies

Authentication and Authorization Service

OAuth2 / RBAC system

Controls access scoped by namespace roles and permissions

Configuration Store

etcd / Consul

Stores configuration data isolated per namespace

Resource Quota Manager

Kubernetes Resource Quotas or custom controller

Enforces compute and storage limits per namespace

Service Discovery

Kubernetes DNS / Consul

Discovers services scoped within namespaces

Microservices Cluster

Kubernetes

Runs microservices isolated by namespaces with network and resource boundaries

Monitoring and Logging

Prometheus, Grafana, ELK stack

Collects and aggregates metrics and logs per namespace

Request Flow

1. Client sends request with namespace identifier to API Gateway

2. API Gateway authenticates user and checks authorization scoped to namespace

3. Request forwarded to Namespace Manager or target microservice within namespace

4. Namespace Manager enforces resource quotas and configuration isolation

5. Service discovery resolves service endpoints within the namespace

6. Microservice processes request isolated from other namespaces

7. Monitoring and logging systems collect data tagged with namespace for visibility

Database Schema

Entities: - Namespace: id (PK), name, owner_team, created_at, resource_quota - User: id (PK), username, email - Role: id (PK), name, permissions - UserRoleNamespace: user_id (FK), role_id (FK), namespace_id (FK) - Configuration: id (PK), namespace_id (FK), key, value - ServiceInstance: id (PK), namespace_id (FK), service_name, endpoint Relationships: - Many-to-many between User and Namespace through UserRoleNamespace - One-to-many from Namespace to Configuration - One-to-many from Namespace to ServiceInstance

Scaling Discussion

Bottlenecks

API Gateway becomes overloaded with many namespace requests

Namespace Manager service bottleneck on namespace lifecycle operations

Configuration store latency under heavy load

Resource quota enforcement delays impacting deployments

Monitoring system overwhelmed by high volume of metrics/logs

Solutions

Use multiple API Gateway instances with load balancing and caching

Shard Namespace Manager by namespace or use distributed coordination

Use highly available and distributed configuration stores with caching

Implement asynchronous quota checks with optimistic concurrency

Aggregate metrics at edge and use sampling to reduce monitoring load

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain why namespace isolation is important for multi-team microservices

Discuss how resource and configuration isolation is achieved

Highlight security with RBAC scoped to namespaces

Describe how service discovery and monitoring are namespace-aware

Address scaling challenges and practical solutions

Practice

1. What is the main purpose of namespace isolation in microservices architecture?

easy

A. To merge all microservices into a single unit

B. To group related microservices and resources to avoid conflicts

C. To increase the size of each microservice

D. To reduce the number of microservices in the system

Solution

1. Step 1: Understand the role of namespaces

   Namespaces group related microservices and their resources to keep them organized and separate.

2. Step 2: Identify the benefit of isolation

   Isolation prevents conflicts between services and helps manage different environments or teams.

3. Final Answer:

   To group related microservices and resources to avoid conflicts -> Option B

4. Quick Check:

   Namespace isolation = grouping and conflict prevention [OK]

Hint: Namespaces group services to avoid conflicts [OK]

Common Mistakes:

• Thinking namespaces merge microservices
• Believing namespaces reduce microservice count
• Confusing namespaces with scaling techniques

2. Which of the following is the correct way to define a namespace in Kubernetes YAML for microservices?

easy

A. apiVersion: v1\nkind: Namespace\nmetadata:\n name: my-namespace

B. apiVersion: v1\nkind: Service\nmetadata:\n name: my-namespace

C. apiVersion: v1\nkind: Pod\nmetadata:\n namespace: my-namespace

D. apiVersion: v1\nkind: Deployment\nmetadata:\n name: my-namespace

Solution

1. Step 1: Identify the resource type for namespaces

   Namespaces in Kubernetes are defined with kind: Namespace.

2. Step 2: Check the YAML structure

   The YAML must have apiVersion: v1, kind: Namespace, and metadata.name set to the namespace name.

3. Final Answer:

   apiVersion: v1 kind: Namespace metadata: name: my-namespace -> Option A

4. Quick Check:

   Namespace YAML uses kind Namespace [OK]

Hint: Namespace YAML uses kind: Namespace and metadata.name [OK]

Common Mistakes:

• Using kind: Service or Deployment instead of Namespace
• Placing namespace under metadata.namespace instead of metadata.name
• Confusing Pod namespace with Namespace resource

3. Given the following Kubernetes setup, what namespace will the pod belong to if no namespace is specified in the pod YAML?

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: app
    image: nginx

medium

A. example-pod

B. kube-system

C. default

D. No namespace assigned

Solution

1. Step 1: Understand Kubernetes default behavior

   If no namespace is specified, Kubernetes assigns the resource to the default namespace automatically.

2. Step 2: Confirm pod YAML lacks namespace field

   The pod YAML does not specify metadata.namespace, so it uses the default namespace.

3. Final Answer:

   default -> Option C

4. Quick Check:

   Missing namespace means default namespace used [OK]

Hint: No namespace specified means default namespace [OK]

Common Mistakes:

• Assuming pod gets a namespace named after pod
• Thinking kube-system is default for all pods
• Believing pod has no namespace if not specified

4. You have two microservices with the same name deployed in different namespaces but they are conflicting. What is the most likely cause?

medium

A. Namespaces are not properly isolated or DNS is misconfigured

B. Microservices must have unique names across all namespaces

C. Namespaces merge services with the same name automatically

D. The microservices are deployed in the same namespace

Solution

1. Step 1: Understand namespace isolation purpose

   Namespaces isolate services so same names can coexist without conflict.

2. Step 2: Identify cause of conflict

   If conflict occurs, likely isolation is broken or DNS resolving services ignores namespaces.

3. Final Answer:

   Namespaces are not properly isolated or DNS is misconfigured -> Option A

4. Quick Check:

   Conflict with same names means isolation or DNS issue [OK]

Hint: Conflicts mean isolation or DNS setup problem [OK]

Common Mistakes:

• Assuming service names must be unique globally
• Believing namespaces merge services automatically
• Ignoring DNS configuration in microservice discovery

5. You want to deploy multiple versions of a microservice for different teams using namespace isolation. Which approach best supports scalability and fault isolation?

hard

A. Merge all microservices into one namespace and use version numbers in URLs

B. Deploy all versions in the same namespace with different service names

C. Use a single namespace and tag microservices with team labels

D. Create separate namespaces per team and deploy microservices with same names inside each

Solution

1. Step 1: Analyze namespace isolation benefits

   Namespaces isolate resources, allowing same service names in different namespaces without conflict.

2. Step 2: Evaluate scalability and fault isolation

   Separate namespaces per team isolate faults and scale independently, improving management and security.

3. Step 3: Compare other options

   Same namespace with different names or labels reduces isolation and complicates management.

4. Final Answer:

   Create separate namespaces per team and deploy microservices with same names inside each -> Option D

5. Quick Check:

   Separate namespaces per team = best isolation and scalability [OK]

Hint: Use separate namespaces per team for isolation and scaling [OK]

Common Mistakes:

• Using one namespace with labels only
• Changing service names instead of namespaces
• Merging all versions in one namespace