How Medium Scaled with Microservices: Lessons to Avoid the “Microservice Syndrome”

21CTO导读：微服务架构的目标是帮助工程团队更快、更安全、更高质量地交付产品，用来解耦相关服务，从而让团队快速迭代，对系统的周边部分影响很低。

In 2012 Medium started with a single‑node.js monolith and a few satellite services, but without a clear microservice strategy. As the system grew and the team expanded, they switched to microservices in 2018.

This article shares Medium’s experience in implementing microservices while avoiding the so‑called “microservice syndrome”.

What Is Microservice Architecture

Microservices are a trend that rescues overloaded and chaotic software engineering. At Medium they define it as multiple loosely coupled services that collaborate, each focusing on a single goal with strong domain and data cohesion.

Design Principles

1. Single Responsibility

Each service should focus on one purpose and do it well.

2. Loose Coupling

Services should have minimal inter‑dependencies; changes to one service must not require changes to others. Communication occurs only via public APIs.

3. High Cohesion

Services encapsulate related behavior and data, so new features involve modifications to a single service only.

Adhering to these three principles is the only way to unlock the full potential of microservice architecture; missing any leads to anti‑patterns.

If a service lacks a single purpose, it drifts toward a “monolith of services”, increasing operational cost. Without loose coupling, changes ripple across services, harming rapid and safe deployments and risking data inconsistency or loss. Without high cohesion, you end up with a distributed monolith that is harder to coordinate, often performing worse than a centralized monolith.

Medium’s Microservice Strategy

1. Build New Services with Clear Value

Only create a service when it delivers clear product or engineering value—otherwise continue improving the existing monolith.

2. Avoid Shared Persistent Storage

Sharing a database couples services tightly, violating loose coupling and high cohesion. Each service should own its data and expose it via APIs or read‑only replicas.

In a microservice architecture, a specific type of data should be owned by a single service; other services access it through APIs or read‑only copies.

3. Service‑Only Business Logic

Each service should focus solely on its own responsibilities and stay out of networking, protocol, deployment, and monitoring concerns, which should be handled by platform tooling.

Network

Medium uses a service mesh (Istio + Envoy) so engineers don’t manage networking directly.

Communication Protocol

They chose gRPC for efficient, cross‑platform RPC, while acknowledging the ubiquity of HTTP + REST + JSON.

Deployment

All services run in containers orchestrated by Kubernetes, with a unified build‑test‑package‑deploy pipeline.

4. Consistent Monitoring

Monitoring (logs, metrics, dashboards, alerts) provides system visibility. Medium adopted DataDog for dashboards and alerts and LightStep for tracing.

5. Prevent Microservice Syndrome Early

Microservices solve problems but introduce new ones; ignoring design principles leads to issues such as over‑fragmented services, language sprawl, mixed build/runtime responsibilities, poor database design, lack of observability, and unnecessary wheel‑reinvention.

6. Embrace Failure

Maintain awareness of potential errors.

Handle RPC errors robustly.

Make failures observable.

Perform failure testing before release.

Build automatic recovery mechanisms.

7. Should We Abandon Monoliths?

While microservices are easier to adopt today, they remain complex. Small teams may still prefer monoliths, but they should design them modularly using the three microservice principles to ease future migration.

Medium’s early decisions—high modularity, shared codebase, and clear service boundaries—allowed them to extract services from a monolith without rewriting everything.

All CRUD operations are handled by a data‑service layer that hides implementation details, enabling services to own their data safely.

Conclusion

Medium’s Node.js monolith served them well for years, but growing complexity and rapid product iteration drove a systematic shift to microservices. Although still early in the journey, they have already seen increased development efficiency, safer experimentation, and the ability to think bigger about product improvements.