Software Deployment is a risky affair. When any new changes are deployed, there exists a chance that the Overall system might break or cease to function completely. This can happen very often if the parties involved fail to follow already pre-established algorithms and methods that aid in safe and successful deployment. The bigger the change footprint, the greater the risk.

To minimize these risks, the Shadow deployment technique should be used.

Shadow deployment involves running a duplicate, parallel environment alongside the production system. This is where the test for the new updates, features, or configurations is done without impacting the live systems.

How Shadow deployment works:

Below are steps for how shadow deployment can be carried out:

1. Set up an identical environment to your production system.

2. Run it alongside the existing versions of the system.

3. All incoming requests to the existing system are also duplicated to the new system.

4. The existing system sends the response to the users.

5. The responses from the existing system and the new system are collected and sent to a comparison system.

6. If everything checks out, only then is the new system activated for processing the user requests.

The best case scenario for Shadow deployment is on large-scale migrations of existing systems. Organizations can transform the architecture of their system without taking a huge risk up-front.

Examples:

• Discord migrating from Cassandra to ScyllaDB.

• Uber migrating from monolithic Postgres to Schemaless.

• Notion's journey to sharding their database.

Thank you for your time. See you in the next.