# Control Planes vs Data Planes

DevFeed: [Control Planes vs Data Planes](<https://devfeed.tech/articles/control-planes-vs-data-planes-12484.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2019/03/17/control.html>)

Author: Marc Brooker

Published: 2019-03-17T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Microservice](<https://devfeed.tech/topics/microservice.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [apis](<https://devfeed.tech/tags/apis.md>), [applications](<https://devfeed.tech/tags/applications.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [availability](<https://devfeed.tech/tags/availability.md>), [cost](<https://devfeed.tech/tags/cost.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [software](<https://devfeed.tech/tags/software.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

The article explains how to design distributed systems by clearly defining component ownership and communication in the system block diagram. It presents the control plane and data plane as a way to separate request-serving components from components responsible for failure tolerance, scaling, and deployments, and discusses how this pattern applies across monolithic and microservices architectures.

## Source excerpt

Control Planes vs Data Planes Are there multiple things here? If you want to build a successful distributed system, one of the most important things to get right is the block diagram: what are the components, what does each of them own, and how do they communicate to other components. It's such a basic design step that many of us don't think about how important it is, and how difficult and expensive it can be to make changes to the overall architecture once the system is in production. Getting the block diagram right helps with the design of database schemas and APIs, helps reason through the availability and cost of running the system, and even helps form the right org chart to build the design. One very common pattern when doing these design exercises is to separate components into a control plane and a data plane, recognizing the differences in requirements between these two roles. No true monoliths The microservices and SOA design approaches tend to push towards more blocks, with each block performing a smaller number of functions. The monolith approach is the other end of the spectrum, where the diagram consists of a single block. Arguments about these two approaches can be endless, but ultimately not important. It's worth noting, though, that there are almost no true monoliths. Some kinds of concerns are almost always separated out. Here's a partial list: Storage. Most modern applications separate business logic from storage and caching, and talk through APIs to their storage. Load Balancing. Distributed applications need some way for clients to distribute their load across multiple instances. Failure tolerance. Highly available systems need to be able to handle the failure of hardware and software without affecting users. Scaling. Systems which need to handle variable load may add and remove resources over time. Deployments. Any system needs to change over time. Even in the most monolithic application, these are separate components of the system, and need to