Your Deployment Pipeline Is Part of the Architecture

Architecture diagrams usually describe a system in a stable state: services are running, databases are available and requests follow clearly defined paths. Production systems, however, spend a significant amount of time changing.

During deployment, old and new versions may run at the same time. Queues can still contain older messages, users may have active sessions and cached frontend assets may outlive the release that produced them.

If the system cannot handle this transition safely, its architecture is incomplete.

Deployment Changes the Runtime

A deployment is not just copying a new artifact to a server. It temporarily changes how the system behaves.

During a rolling deployment:

• Multiple application versions may serve traffic simultaneously.
• An older service may call a newer API.
• Queued messages may be processed after their producer has been updated.
• Users may continue sessions started before the release.
• Cached assets may reference code from different versions.

Backward compatibility is therefore an architectural requirement. If every change requires all components to be stopped and upgraded together, the system is tightly coupled regardless of how independent it looks on a diagram.

Database Changes Must Support Transition

Database migrations have the same problem. Renaming or removing a column in the same release that updates the application may fail while the previous version is still running.

A safer change is usually incremental:

1. Add the new schema while keeping the old one.
2. Deploy code compatible with both versions.
3. Migrate existing data.
4. Remove the old schema in a later release.

The important point is not the exact process. It is that schema evolution and application deployment must be designed together.

Microfrontends Have Version Boundaries Too

Microfrontends are often introduced to allow teams to build and deploy independently. In practice, the browser may run several versions of the application at the same time.

A user can load an older shell from a cache and a newer remote module from the server. One microfrontend may expect a different shared dependency, event format or API response than another. A deployment that works after a clean refresh may fail for a user with an existing session.

Independent deployment requires stable contracts between microfrontends, not just separate repositories and pipelines. Shared events, routing, authentication state and common dependencies need explicit compatibility rules.

If every frontend must be released in a specific order, independent delivery exists only on paper.

Rollback Is More Than a Button

A pipeline may provide a button that deploys the previous artifact, but that does not guarantee the system can be rolled back.

The failed release may have already changed data, published events or triggered external operations. In many cases, rolling forward with a fix or disabling the feature is safer than restoring the previous version.

A realistic recovery strategy should answer:

• Is the previous version compatible with changes made by the new one?
• Can the new behaviour be disabled with a feature flag?
• What happens to messages already published?
• How quickly will the team detect that something is wrong?

This is where observability becomes part of delivery. Healthy containers are not enough—the pipeline should verify error rates, latency and critical business operations during a staged or canary rollout.

Conclusion

A system is not well architected only because its components have clean boundaries and communicate through well-designed interfaces. It must also be possible to change that system safely.

Backward compatibility, version coexistence, migration strategy, observability and recovery should be considered while designing the application - before it is ready for production.

The deployment pipeline is not just a way to deliver new version - it is executable architecture.