Container networking in Microservices - System Design Exercise

Design: Container Networking System

Design the networking layer for containerized microservices including intra-host and inter-host communication, service discovery, and network isolation. Out of scope are container orchestration scheduling and storage networking.

Functional Requirements

FR1: Enable communication between containers within the same host

FR2: Enable communication between containers across different hosts

FR3: Support service discovery for containers to find each other dynamically

FR4: Provide network isolation and security between different container groups

FR5: Allow containers to expose ports to external clients

FR6: Support scalability to thousands of containers

FR7: Ensure low latency and high throughput for container communication

Non-Functional Requirements

NFR1: Handle up to 10,000 containers across multiple hosts

NFR2: Network latency p99 should be under 10ms for container-to-container communication

NFR3: Availability of networking should be 99.9%

NFR4: Support dynamic container lifecycle (start, stop, move) without manual network reconfiguration

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

❓ Question 7

Key Components

Container network interface (CNI) plugins

Overlay network technologies (e.g., VXLAN, GRE)

Service discovery components (e.g., DNS, etcd, Consul)

Network proxies and load balancers

Network policy enforcement modules

IP address management system

Host network stack and virtual interfaces

Design Patterns

Overlay networking for cross-host container communication

Service mesh for advanced routing and security

Sidecar proxy pattern for network traffic control

Network namespaces for isolation

Load balancing and ingress routing

Dynamic IP allocation and DHCP for containers

Reference Architecture

 +----------------+       +----------------+       +----------------+
 |   Container    |       |   Container    |       |   Container    |
 |    Host A      |       |    Host B      |       |    Host C      |
 | +------------+ |       | +------------+ |       | +------------+ |
 | | Container  | |       | | Container  | |       | | Container  | |
 | | Network    | |       | | Network    | |       | | Network    | |
 | | Namespace  | |       | | Namespace  | |       | | Namespace  | |
 | +------------+ |       | +------------+ |       | +------------+ |
 |      |         |       |      |         |       |      |         |
 | +------------+ |       | +------------+ |       | +------------+ |
 | | CNI Plugin | |       | | CNI Plugin | |       | | CNI Plugin | |
 | +------------+ |       | +------------+ |       | +------------+ |
 +-------|--------+       +-------|--------+       +-------|--------+
         |                        |                        |
         | Overlay Network (VXLAN/GRE) connecting hosts across data center
         |                        |                        |
 +-------v--------------------------------------------------------v-------+
 |                          Physical Network / Cloud Network               |
 +-------------------------------------------------------------------------+

 +----------------+       +----------------+       +----------------+
 | Service        |       | Network Policy |       | Service        |
 | Discovery (DNS)|       | Controller     |       | Mesh / Proxy   |
 +----------------+       +----------------+       +----------------+

Components

Container Network Interface (CNI) Plugin

Calico, Flannel, Weave

Manages container network namespaces, assigns IPs, and sets up virtual interfaces for containers on each host.

Overlay Network

VXLAN, GRE

Creates a virtual network over the physical network to enable container communication across hosts.

Service Discovery

CoreDNS, etcd

Allows containers to find each other dynamically by resolving service names to IP addresses.

Network Policy Controller

Kubernetes Network Policies, Calico Policies

Enforces security rules and network isolation between containers and services.

Load Balancer / Ingress Controller

Envoy, NGINX, HAProxy

Routes external traffic to container services and balances load among container instances.

IP Address Management (IPAM)

Built-in CNI IPAM or external IPAM tools

Allocates and tracks IP addresses for containers to avoid conflicts.

Request Flow

1. 1. Container starts on a host; CNI plugin assigns an IP and sets up network namespace.

2. 2. Container registers its service and IP with the service discovery system.

3. 3. When a container wants to communicate with another, it queries service discovery for the target IP.

4. 4. The container sends packets through its virtual interface; packets are encapsulated by the overlay network if the destination is on a different host.

5. 5. Overlay network routes packets across the physical network to the destination host.

6. 6. Network policy controller checks if communication is allowed based on defined rules.

7. 7. Packets are delivered to the destination container's network namespace.

8. 8. For external access, traffic hits the load balancer or ingress controller, which routes it to the appropriate container.

Database Schema

Entities: - Container: id (PK), host_id (FK), ip_address, network_namespace, status - Host: id (PK), hostname, physical_ip - Service: id (PK), name, selector_labels - ServiceInstance: id (PK), service_id (FK), container_id (FK), ip_address - NetworkPolicy: id (PK), name, rules (JSON), applied_to (labels) Relationships: - Host 1:N Container - Service 1:N ServiceInstance - NetworkPolicy applies to Containers via labels

Scaling Discussion

Bottlenecks

Overlay network encapsulation overhead causing latency increase at high scale

Service discovery becoming a bottleneck with thousands of service instances

IP address exhaustion in flat IP space

Network policy enforcement performance degradation with many rules

Load balancer capacity limits under heavy external traffic

Solutions

Use efficient overlay protocols and hardware offloading to reduce encapsulation overhead

Implement hierarchical or sharded service discovery to distribute load

Use multiple IP address pools or IPv6 to expand address space

Optimize network policy rules and use scalable enforcement engines

Deploy multiple load balancers with DNS-based load distribution and autoscaling

Interview Tips

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

Explain how container networking differs from traditional networking

Discuss the role of CNI plugins and overlay networks

Highlight service discovery integration and dynamic IP management

Emphasize network isolation and security via policies

Address scalability challenges and realistic solutions

Mention trade-offs between complexity and performance

Practice

1. What is the main purpose of container networking in microservices?

easy

A. To allow containers to communicate with each other

B. To store container data persistently

C. To build user interfaces for containers

D. To monitor container CPU usage

Solution

1. Step 1: Understand container networking role

   Container networking connects containers so they can send data and messages to each other.

2. Step 2: Compare with other options

   Storing data, building interfaces, and monitoring CPU are not related to networking.

3. Final Answer:

   To allow containers to communicate with each other -> Option A

4. Quick Check:

   Container networking = communication [OK]

Hint: Networking means communication between containers [OK]

Common Mistakes:

• Confusing networking with storage
• Thinking networking builds UI
• Mixing monitoring with networking

2. Which Docker command creates a user-defined network named mynet?

easy

A. docker create network mynet

B. docker network create mynet

C. docker network new mynet

D. docker net create mynet

Solution

1. Step 1: Recall Docker network creation syntax

   The correct command is docker network create <name>.

2. Step 2: Match options with syntax

   Only docker network create mynet matches the correct syntax exactly.

3. Final Answer:

   docker network create mynet -> Option B

4. Quick Check:

   docker network create = correct syntax [OK]

Hint: Remember: 'docker network create' is the right command [OK]

Common Mistakes:

• Swapping 'create' and 'network' order
• Using 'new' instead of 'create'
• Shortening 'network' to 'net' incorrectly

3. Given two containers web and db connected on a user-defined network mynet, what happens when web tries to ping db by container name?

medium

A. Ping succeeds because containers can resolve names on the same user-defined network

B. Ping fails because container names are not resolvable

C. Ping succeeds only if IP addresses are used, not names

D. Ping fails because containers cannot communicate on user-defined networks

Solution

1. Step 1: Understand user-defined network DNS resolution

   User-defined Docker networks provide automatic DNS resolution of container names.

2. Step 2: Apply to ping scenario

   Since both containers are on mynet, web can ping db by name successfully.

3. Final Answer:

   Ping succeeds because containers can resolve names on the same user-defined network -> Option A

4. Quick Check:

   User-defined network = name resolution works [OK]

Hint: User-defined networks enable container name resolution [OK]

Common Mistakes:

• Assuming container names are never resolvable
• Thinking IP addresses are always required
• Believing user-defined networks block communication

4. You created two containers on the default bridge network but they cannot communicate by container name. What is the likely cause?

medium

A. Container names must be IP addresses on default bridge

B. Containers must be on different networks to communicate

C. Default bridge network does not support automatic container name resolution

D. Docker daemon is not running

Solution

1. Step 1: Recall default bridge network limitations

   The default bridge network does not provide automatic DNS for container names.

2. Step 2: Analyze communication failure

   Without name resolution, containers cannot reach each other by name on default bridge.

3. Final Answer:

   Default bridge network does not support automatic container name resolution -> Option C

4. Quick Check:

   Default bridge = no name resolution [OK]

Hint: Default bridge lacks container name DNS [OK]

Common Mistakes:

• Thinking containers must be on different networks to communicate
• Confusing container names with IP addresses
• Assuming Docker daemon is stopped without checking

5. You want to isolate microservices into separate networks for security but allow only the api service to communicate with db. Which design best achieves this?

hard

A. Create separate networks but connect all containers to all networks.

B. Connect all services to a single network and use firewall rules inside containers.

C. Use the default bridge network for all containers and rely on container names.

D. Create two networks: api-net and db-net. Connect api to both networks, db only to db-net.

Solution

1. Step 1: Understand network isolation and selective communication

   Separating services into different networks isolates traffic. Connecting api to both networks allows it to talk to db while others cannot.

2. Step 2: Evaluate options for security and communication

   Create two networks: api-net and db-net. Connect api to both networks, db only to db-net. isolates db and allows only api access. Other options either lack isolation or allow unwanted access.

3. Final Answer:

   Create two networks: api-net and db-net. Connect api to both networks, db only to db-net. -> Option D

4. Quick Check:

   Separate networks + selective connection = secure communication [OK]

Hint: Use multiple networks and connect only needed containers [OK]

Common Mistakes:

• Putting all containers on one network without isolation
• Connecting all containers to all networks
• Relying on default bridge network for security