Microservice Architecture at Medium: Lessons, Principles, and Strategies

Medium began its journey in 2012 with a monolithic Node.js application and, as the system grew in complexity and the team expanded, shifted to a microservice architecture in early 2018 to address performance bottlenecks, slow iteration, and the need for safer, faster product delivery.

Microservice architecture is defined by three design principles: single responsibility (each service does one thing well), loose coupling (services know little about each other and communicate only via well‑defined APIs), and high cohesion (related behavior and data are encapsulated within a service). Violating any of these leads to anti‑patterns such as distributed monoliths, tight coupling, or fragile deployments.

The move was driven by concrete problems: heavy I/O‑bound workloads that Node.js handled poorly, the monolith’s impact on deployment speed and team autonomy, and the difficulty of scaling specific workloads without over‑provisioning the entire system.

Medium adopted seven practical strategies: (1) build new services only when they deliver clear product or engineering value; (2) treat shared persistent storage as harmful and give each service its own data store; (3) separate service construction from service governance; (4) enforce consistent, high‑quality observability across all services; (5) reuse existing code when possible instead of rebuilding from scratch; (6) design for failure by testing and automating recovery; and (7) avoid the “microservice syndrome” by adhering to the three core principles from day one.

For governance, Medium uses a service mesh (Istio and Envoy) to abstract networking concerns, chooses gRPC for efficient, typed inter‑service communication, and runs all services in containers orchestrated by a hybrid of AWS ECS and Kubernetes. An internal system called BBFD standardises build, test, packaging, and deployment metadata, allowing each service to declare its own runtime parameters while the platform handles the rest.

Observability is achieved through automatic DataDog dashboards, alerts, and logs for every service, supplemented by LightStep for performance insights. The article concludes that while microservices are not a silver bullet, a well‑engineered modular monolith can serve as a solid foundation for a later migration, and the early benefits observed at Medium include faster iteration, safer releases, and the ability to experiment with new technologies.