Skip to main content
On this page

CQRS

The etg24 integration architecture is built on Command Query Responsibility Segregation (CQRS). Rather than relying on overloaded REST endpoints where side effects can be ambiguous, every operation is explicitly divided into either a read operation (Query) or a state mutation (Command).

Queries vs. Commands

  • Queries retrieve data without modifying state. They are idempotent, safe to retry automatically upon network failure, and can be executed by credentials with read-only scopes.
  • Commands mutate state — creating, updating, or archiving entities. They represent explicit domain actions, validate business rules, trigger domain events, and write attributable entries into the audit log.

In the REST API, this architectural split is explicitly reflected in the path structure:

GET  /propertymanagement/v2/query/contacts           Fetch a paginated list of contacts
GET  /propertymanagement/v2/query/contacts.show      Retrieve a single contact by ID
POST /propertymanagement/v2/command/contacts.create  Create a new contact entity
POST /propertymanagement/v2/command/contacts.update  Update an existing contact

The MCP server enforces the exact same paradigm: every tool in our catalogue is classified as either a query tool or a command tool. Autonomous AI agents can invoke query tools without risk of unintended side effects, reserving command invocations for deliberate state changes.

Practical benefits for your integrations

  1. Clear security boundaries: Read-only API keys map cleanly to query endpoints. A key restricted to read access can execute all permitted queries, while commands are rejected at the gateway level. See Permission scopes.
  2. Deterministic audit logging: Every state-changing command is tracked with the actor ID, exact input parameters, and resulting entity changes. See Audit trail & change attribution.
  3. Reversible state changes: Because commands represent explicit actions and deletions use soft deletes, mutations can be inspected and reversed safely. See Soft delete & rollback.

Design rule for agent development

When building workflows or configuring agent instructions:

  • Use Queries for context gathering, status checks, and data retrieval. They carry zero operational risk and can be safely retried.
  • Use Commands when an action must alter the database or trigger downstream processes (such as sending a notification or filing an invoice). Ensure command inputs are strictly validated before execution.