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

What Is Microservice Architecture?

Microservices are loosely coupled services that each focus on a single purpose, maintain high cohesion of related behavior and data, and communicate only through well‑defined interfaces.

The three design principles are:

Single purpose – each service does one thing well.

Loose coupling – changes in one service do not require changes in others.

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

Microservices are not merely small code units, nor are they required to use new technology or be built from scratch; they must simply obey the three principles.

Why Now?

Medium’s monolithic Node.js app became a performance bottleneck, slowed product development, made scaling specific tasks difficult, and prevented safe experimentation with new technologies. Moving to microservices enables faster, safer releases, independent scaling, and technology‑agnostic service development.

Microservice Strategy

Seven early‑stage strategies helped the transition:

Build new services that deliver clear product or engineering value.

Avoid shared monolithic persistent storage.

Separate “building” from “running” services.

Ensure thorough, consistent observability.

Reuse existing code when possible; don’t always start from scratch.

Design for failure and implement graceful recovery.

Avoid the “microservice syndrome” from day one.

Each strategy is explained with examples, such as modeling data ownership, using API‑only access to shared data, and employing service meshes (Istio/Envoy) and gRPC for networking and communication.

Decoupling Build and Run

Running services should be independent of the technology used to build them. Modern container orchestration, service meshes, and standardized RPC (gRPC) simplify this separation, allowing engineers to focus on business logic.

Observability

Consistent logging, tracing, metrics, dashboards, and alerts are essential. Medium automatically provisions DataDog dashboards and LightStep tracing for every service to maintain system‑wide visibility.

Respecting Failure

Distributed systems inevitably experience failures; teams should anticipate them, add robust RPC error handling, maintain observability, test failure scenarios before release, and automate recovery where possible.

Avoiding Microservice Syndrome

Common symptoms include over‑modeling services, excessive language diversity, coupling build and run concerns, ignoring data modeling, lacking observability, and creating new services instead of fixing existing ones.

Should We Stop Building Monoliths?

While microservices are easier to adopt today, monolithic architectures remain appropriate for small teams. Building a modular monolith first makes later migration smoother.

Conclusion

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