Preview — Pro guide
You are seeing a portion of this guide. Sign in and upgrade to unlock the full article, quizzes, and interview answers.
Sections
Related Guides
Metric Anomaly Triage: Is This a Real Problem or an Instrumentation Bug?
Production Engineering
On-Call Incident Response: The First 30 Minutes
Production Engineering
A/B Test Critique: Finding Flaws in Experiment Designs
Production Engineering
Microservices Architecture: Decomposition, Service Mesh, Circuit Breakers & Saga Pattern
High-Level Design
Refactoring Patterns: Strangler Fig, Extract Class, Anti-Corruption Layer & Legacy Modernization
Low-Level Design
Rewrite vs. Refactor: How to Make the Call Without Destroying the Business
Framework for evaluating whether a legacy service should be rewritten from scratch or incrementally improved. Covers second system syndrome, the strangler fig pattern, hidden functionality risk, how to estimate rewrite cost realistically, and the conditions where a rewrite is genuinely the right choice. A classic senior and staff engineering judgment question.
The Scenario
Service X is 6 years old. It was written by engineers who have since left the company. It has no tests, uses a deprecated framework (Rails 4), and owns the user authentication and session management for 20% of company revenue. The team estimates they spend 40% of their sprint capacity fighting fires in this service rather than shipping features. Three engineers have proposed a full rewrite in a modern stack.
Should you do it?
This question appears in senior engineering interviews as a judgment call. The interviewer is not looking for "yes" or "no" — they are watching whether you (a) have a framework for making this decision, (b) know the failure modes of each option, and (c) understand what information you need before deciding.
The default answer at most experienced engineering organizations is: no, do not rewrite. Find a way to incrementally improve. But this is not always correct. Understanding when to override this default is what separates senior from staff engineers.