Talis is a service designed to manage and orchestrate distributed systems deployments, with a focus on blockchain networks and testing environments. This document outlines the high-level architecture of Talis, describing its core components, data models, API design, and internal service interactions.
Talis is built around four primary entities that work together to provide a comprehensive deployment and management solution:
- Owners: The users of the Talis system who initiate and manage deployments
- Projects: Scopes of work that represent a specific deployment goal (e.g., test environment, long-running chain, testnet)
- Tasks: Discrete actions that Talis executes to achieve the desired state
- Instances: The actual deployed resources (servers, nodes, etc.) managed by Talis
- Represents a user of the Talis system
- Manages projects and has permissions to perform actions
- Can create and monitor multiple projects
- Represents a scope of work (test, chain, testnet)
- Contains configuration for the desired deployment
- Associated with multiple instances and tasks
- Owned by a specific owner
- Represents a discrete action to be executed
- Contains all necessary information for execution
- Has a clear lifecycle (pending, running, completed, failed)
- Associated with a project and potentially specific instances
- Represents a deployed resource
- Contains metadata about the deployment (IP, status, configuration)
- Associated with a specific project
- May have multiple tasks associated with it
The API is designed from an RPC model in mind, following these principles:
-
Request-Body Focused
- Prioritizes POST requests with structured request bodies
- Enables strong type validation and clear contract definition
- Makes SDK integration straightforward and maintainable
-
Synchronous Database Operations
- API calls block until database operations complete
- Successful response guarantees successful database update
- Provides clear consistency guarantees to clients
-
Asynchronous Task Execution
- Long-running operations are handled asynchronously
- Tasks are created and tracked in the database
- Clients can poll for task status and completion
Users should import data types for the API defined in the API package. The API package should import the data types from the internal package.
The only types defined in the API package should be the request and response types.
Following this flow should allow internal to primarily use the DB models for types to reduce the amount of type definitions.
- User submits request through API
- Request is validated
- Database is updated synchronously
- Project/Instance/Task records created/updated
- All related entities are updated in a transaction
- API returns success response
- Asynchronous processing begins
- TaskExecutor routine runs as a background process
- Continuously monitors Task database for new entries
- Picks up pending tasks for execution
- Updates task status during execution
- Marks tasks as completed or failed
- Updates related entities with results
- User submits project creation request with 100 instances
- API validates request
- Database transaction begins
- Project record created
- Instance records created
- Associated tasks created
- Transaction commits
- API returns success
- TaskExecutor begins processing instance creation tasks
- Instances are created asynchronously
- Task and instance statuses are updated as work completes
Note: This architecture represents the target design of Talis. The actual implementation is a work in progress, and some components may be partially implemented or planned for future development.