---
type: concept
x-llmwiki:
  schemaVersion: "0.1"
  contentHash: 6897e65cd3f648877720a68578cc3960b4b08a405e3a90aa646c1974f836126b
  pageDirectory: concepts
  sources:
    - model-deployment-patterns-databricks-on-aws.md
  confidence: 0.9
  provenanceState: extracted
  freshnessStatus: unverified
  aliases:
    - asynchronous-model-and-code-lifecycles
    - Code Lifecycles and Asynchronous Model
    - AMACL
  citations:
    - file: model-deployment-patterns-databricks-on-aws.md
title: Asynchronous Model and Code Lifecycles
description: The fundamental concept in MLOps that model artifacts and the code that produces them evolve on different cadences, enabling scenarios like weekly model retraining without code changes or code updates without retraining.
tags:
  - mlops
  - lifecycle-management
timestamp: "2026-06-19T19:42:19.232Z"
---

# Asynchronous Model and Code Lifecycles

**Asynchronous Model and Code Lifecycles** refers to the property of ML system development where model artifacts and the code that creates them can evolve independently and on different cadences. This asynchrony is a fundamental characteristic of ML systems and has direct implications for deployment strategies and environment architecture.

## Overview

ML models are created by code, but the resulting model artifacts and their generating code do not necessarily change together. New model versions and code changes can happen at different times and on different schedules. This decoupling means that teams must design their deployment processes to handle asynchronous updates. ^[model-deployment-patterns-databricks-on-aws.md]

## Common Scenarios

### Scenario 1: Frequent Retraining, Stable Code

For use cases like fraudulent transaction detection, an ML pipeline may retrain a model weekly to incorporate new data. The underlying training code may change infrequently, but the model artifact is updated regularly to reflect the latest patterns in the data. In this case, the model lifecycle is much more active than the code lifecycle. ^[model-deployment-patterns-databricks-on-aws.md]

### Scenario 2: Stable Model, Active Code

For computationally expensive models, such as large deep neural networks for document classification, retraining is infrequent. However, the code that deploys, serves, and monitors the model can be updated regularly without retraining the model. Here, the code lifecycle is more active, while the model artifact remains relatively stable. ^[model-deployment-patterns-databricks-on-aws.md]

## Deployment Patterns

The asynchronous nature of model and code lifecycles leads to two primary deployment patterns, which differ in whether the model artifact or the training code is promoted toward production.

### Deploy Code (Recommended)

In this pattern, the code to train models is developed in the development environment. The same code moves through staging and then to production. The model is trained in each environment:

- **Development environment**: Initial training as part of model development.
- **Staging environment**: Training on a limited subset of data as part of integration tests.
- **Production environment**: Training on full production data to produce the final model.

This approach is recommended by Databricks and incorporated into the standard MLOps workflow.

**Advantages:**
- Models can be trained on production data in the production environment, which is useful when access to production data is restricted.
- Automated model retraining is safer because the training code is reviewed, tested, and approved for production.
- Supporting code follows the same lifecycle as model training code, with both undergoing integration tests in staging.

**Disadvantages:**
- Data scientists may face a learning curve when handing off code to collaborators; predefined project templates and workflows can help mitigate this.

Data scientists must be able to review training results from the production environment, as they have the domain expertise to identify and fix ML-specific issues.

**Hybrid approach:** If the model must be trained on the full production dataset but only in staging, teams can deploy code to staging, train the model there, and then deploy the model artifact to production. This saves training costs in production but adds an extra operational cost in staging. ^[model-deployment-patterns-databricks-on-aws.md]

### Deploy Models

In this pattern, the model artifact is generated by training code in the development environment. The artifact is then tested in staging before being deployed to production.

Consider this option when:
- Model training is very expensive or hard to reproduce.
- All work occurs in a single Databricks workspace.
- You are not working with external repositories or a CI/CD process.

**Advantages:**
- Simpler handoff for data scientists.
- The model only needs to be trained once, which is beneficial when training is expensive.

**Disadvantages:**
- If production data is inaccessible from the development environment (often the case for security reasons), this architecture may be unworkable.
- Automated model retraining is difficult because the team responsible for deploying to production may not accept models trained in the development environment.
- Supporting code (feature engineering, inference, monitoring pipelines) must be deployed to production separately.

Typically, each environment (development, staging, production) corresponds to a [Unity Catalog](/concepts/unity-catalog.md) catalog. ^[model-deployment-patterns-databricks-on-aws.md]

## Lifecycle Comparison

The code lifecycle for each deployment pattern differs across environments:

- **Deploy code pattern:** Unit tests and integration tests are run in the development environment. Final unit and integration testing is performed in the staging environment. Training code is promoted through environments, and the final model is trained in production.
- **Deploy models pattern:** Final unit and integration testing is performed in the development environment. The model artifact is promoted through staging to production without retraining. ^[model-deployment-patterns-databricks-on-aws.md]

## Related Concepts

- MLOps Workflow — The recommended lifecycle management approach for ML on Databricks.
- Model Deployment Patterns — The two patterns for moving ML artifacts through staging into production.
- [Unity Catalog](/concepts/unity-catalog.md) — Used to map environments to catalogs in the deployment workflow.
- [Model Serving](/concepts/model-serving.md) — Serving infrastructure that may be updated independently of model retraining.
- Feature Engineering Pipeline — Supporting code that must be deployed separately in the deploy models pattern.
- [CI/CD for ML](/concepts/cicd-for-ml-pipelines.md) — Continuous integration and delivery practices that support model and code lifecycle management.

## Sources

- model-deployment-patterns-databricks-on-aws.md

# Citations

1. [model-deployment-patterns-databricks-on-aws.md](/references/model-deployment-patterns-databricks-on-aws-231ed92b.md)
