Designers love to talk about a single source of truth. A singular, universal solution that forms the foundation of everything we do. A pervasive, all-encompassing system.
A design system.
But, is that centralized, monolithic approach to structuring and documenting all things design the best way to go? I’m not sold on it.
Sure, structuring a design system as a one-size-fits-all repository sounds wonderful. And it might work out at first, but our teams will likely continue to expand. As our products grow, the number of designers working on them rises. And soon enough there’s a dozen — or several dozen — designers working on the same system.
And that’s when this monolith starts to crack, crumbling under the ever-increasing size of the design system. With every use case added or design pattern documented, its glamorous facade starts to fade.
Microservices for designers
In recent years, the microservice has picked up a tremendous amount of momentum. Touted by large-scale, complex services such as Uber, Netflix, and Amazon as the best way to tackle the complexity of scaling system architecture, it’s easy to see where its popularity stems from.
For those unfamiliar with the term, Amazon describes microservices as follows:
Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs.
[…] Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.
Microservices allow engineering organizations to split services into small autonomous, functioning parts. Where companies used to construct a monolithic system architecture, nowadays they increasingly favor the idea of building self-contained services. This reduction in dependencies allows them to build faster, scale more easily, and maintain a continuous pace in innovation.