Shipping Breaking Changes Without Breaking Production

Early in our careers, we tend to think a feature is ready once the API is correct, tested, and returns the expected response. Working on production systems consumed by web, mobile, and internal services taught me otherwise: a backend change can be technically correct and still break the product.

In this talk, I'll walk through a real feature I built: evolving speaker roles from a single role per speaker (1:1) to multiple roles (many-to-many), in a system with thousands of existing records and clients that couldn't all update at once.

We'll cover:
- Why your API contract is bigger than the endpoint, and how renaming a single field can break older clients
- Treating backward compatibility as part of feature development, not an afterthought
- Redesigning the database safely with a transition state: introduce the new model, dual write, migrate, switch, and only then remove the legacy path
- Turning "nobody uses this field anymore" into evidence, using logs and metrics before deleting code
- Designing observability before deployment, so you can validate a migration in production

You'll leave with a practical, step-by-step approach for evolving APIs and data models in live systems, and a different question to ask before every change: not only "does the new feature work?", but "can the system safely move from its current state to the new one?"