An interface is backward compatible when existing clients that obeyed the old contract continue to work after the provider changes.

Compatibility is about behavior, not only syntax. Keeping the same function name while changing units, error meaning, default values or ordering guarantees can still break callers.

Additive changes are often easier to make compatible than destructive ones. A provider can introduce a new optional field while continuing to understand old requests, whereas removing a field or changing its meaning requires coordination with existing clients.

For networked or independently deployed components, old and new versions may coexist during a rollout. Interfaces should therefore tolerate the combinations that the deployment process can actually create.

When a breaking change is unavoidable, migration needs an explicit transition: introduce the new behavior, move consumers, then remove the old contract only after it is no longer needed.

Compatibility turns interface evolution from a synchronized rewrite into a sequence of states that remain usable while software changes.