Medium’s Journey to Microservices: Principles, Strategies, and Lessons Learned

What Is Microservice Architecture?

The goal of a microservice architecture is to enable engineering teams to deliver products faster, safer, and with higher quality by decoupling services so that changes have minimal impact on the rest of the system.

Medium started in 2012 with a single‑node Node.js monolith, added a few satellite services, and only in early 2018 adopted a systematic microservice strategy as the system grew more complex and the team expanded.

In a microservice architecture, many loosely‑coupled services work together, each focusing on a single purpose with highly cohesive behavior and data.

The three design principles are:

Single purpose – each service does one thing well.

Loose coupling – services know little about each other; changes to one do not require changes to others.

High cohesion – related behavior and data are encapsulated within the service.

Microservices are not merely small pieces of code, nor are they always built with the newest technology, and they do not have to be created from scratch if a well‑architected monolith already exists.

Why Now?

Medium’s monolithic Node.js app became a performance bottleneck for CPU‑intensive and I/O‑heavy tasks, slowed product development because all engineers worked on a tightly‑coupled codebase, and prevented safe experimentation with new technologies.

Adopting microservices allows changes to reach production within an hour, reduces the risk of affecting unrelated parts, enables independent scaling of different workloads, and lets each service use the most appropriate technology stack.

Microservice Strategy

Seven (actually eight) strategies that helped Medium in the early adoption phase:

Build new services that deliver clear product or engineering value.

Avoid monolithic persistent storage; each service owns its data.

Decouple "building" from "running" services.

Ensure thorough and consistent observability.

Reuse existing code when possible; not every service must be built from scratch.

Respect failures because they will happen.

Avoid microservice‑syndrome from day one.

Repeat the principle of building services with clear value.

Each new service should be justified by product or engineering value; otherwise it stays in the monolith.

Persistent Storage Is Harmful

Sharing a database across services leaks implementation details, violates loose coupling and high cohesion, and makes coordinated changes difficult. Instead, each service should own its data and expose it via an API or provide read‑only, denormalized copies for other services.

Example: a recommendation service needs post data stored in DynamoDB. Options include:

Option A – a dedicated Post service owns the data and other services access it via API.

Option B – the monolith notifies the recommendation service of updates, possibly via a queue.

Option C – an ETL pipeline creates a read‑only replica for the recommendation service.

Decouple "Build" and "Run"

Running services should be independent of how they are built. Medium uses containers, a mixed AWS ECS/Kubernetes orchestration, Istio/Envoy service mesh, and gRPC for efficient, type‑safe RPC communication, avoiding the overhead of REST/JSON for server‑to‑server traffic.

Medium also built an internal system called BBFD to standardize building, testing, packaging, and deploying services across different technology stacks.

Thorough and Consistent Observability

Observability includes logging, tracing, metrics, dashboards, and alerts. Medium equips every service with DataDog dashboards, alerts, log search, and extensive use of LightStep to understand system performance.

Not Every New Service Needs to Be Built From Scratch

If existing Node.js code already solves the problem well, Medium extracts it into a separate service, gaining all microservice benefits without rewriting the logic.

Respect Failures Because They Will Happen

Expect failures, add extra handling for RPC calls, maintain good observability, test failures before releasing new services, and build automatic recovery where possible.

Avoid Microservice Syndrome From Day One

Common symptoms include poorly modeled services, excessive language/technology diversity, coupling build and run concerns, ignoring data modeling, lacking observability, creating new services instead of fixing existing ones, and missing a holistic system view.

Should We Stop Building Monoliths?

While new tooling makes microservices easier, they still add complexity. Small teams may stick with a well‑modularized monolith and later migrate to microservices as the system and team grow.

Starting with a monolith is fine, but ensure it is modular and follows the three microservice principles (single purpose, loose coupling, high cohesion) even if all services run in the same process.

Conclusion

Medium’s monolithic Node.js app served well for years but eventually slowed delivery and iteration. Systematic adoption of microservices has dramatically improved development speed, enabled bold product improvements, and allowed safe experimentation with new technologies.

Interested engineers can view Medium’s job page; those keen on microservices may explore senior full‑stack or senior platform engineer roles.

Thank you for reading. Feel free to leave comments or questions about our microservice journey. ¹ In this article, “microservice” refers either to the architecture as a whole or to an individual service. ² Using production data in development is a trade‑off; Medium only uses engineers’ own accounts and respects user privacy.