Skip to content

Design Proposal: Atomic Multi-Component Deployment for DrasiLib#12

Open
danielgerlag wants to merge 1 commit into
mainfrom
design/atomic-deploy
Open

Design Proposal: Atomic Multi-Component Deployment for DrasiLib#12
danielgerlag wants to merge 1 commit into
mainfrom
design/atomic-deploy

Conversation

@danielgerlag
Copy link
Copy Markdown
Contributor

Summary

Introduces a design proposal for atomic multi-component deployment in DrasiLib using a staging model.

Problem

Deploying multiple components (sources, queries, reactions) as a logical unit is not atomic. Failures mid-deployment leave the system in a partially-deployed state requiring manual recovery.

Proposed Solution

A staging model that separates slow preparation from fast atomic commitment:

  • Staging phase: Components are initialized privately with no shared locks held
  • Commit phase: A single GraphTransaction atomically registers all components (sub-millisecond, in-memory only)
  • On failure: Staging area is dropped — live graph is never touched, no rollback needed

Key Benefits

  • All-or-nothing deployment semantics
  • No blocking during slow initialization
  • Eliminates compensating rollback complexity (~100 lines of rollback code removed from instance clone)
  • Concurrency-safe without mutexes

Document Location

drasi-lib/Atomic-Deploy/00-atomic-multi-component-deployment.md

Introduces a staging model for multi-component deployments that separates
slow preparation from fast atomic commitment. This eliminates partial
deployment states, compensating rollback complexity, and lock contention
during component initialization.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant