A change does not have to end in a database. Aestus can call the API of the system that needs it, or publish it as an event on your enterprise broker for every team to use. The other way round, a queue, topic or API can start a flow that keeps a database, the lakehouse, a graph or a search index current.
How Aestus reads changes from each system, and how it writes them.
As a source: A consumer group that commits its offsets once Aestus has stored the change; tombstones become deletes; schemas from the registry.
As a target: One event per change, keyed so each record stays in order; log-compacted topics hold the latest state per key; Avro, Protobuf or JSON with a schema registry.
As a source: Your queues, or streams for replay from any point.
As a target: Messages published to your exchange with routing keys per table and operation, confirmed by the broker.
As a source: Queues and topic subscriptions, with sessions for order per key.
As a target: Messages with the record's group as session, so they arrive in order, and a message id for duplicate detection.
As a source: Partitions with a checkpoint store, or the Kafka endpoint.
As a target: Events with the record's group as partition key.
As a source: FIFO queues and Kinesis shards.
As a target: FIFO messages grouped per record with a deduplication id; Kinesis records by partition key; EventBridge events for routing.
As a source: Subscriptions with ordering keys.
As a target: Messages with the record's group as ordering key.
As a source: JetStream consumers and topic subscriptions, from services to IoT devices.
As a target: Subjects and topics per table, with message ids for deduplication.
As a source: Polling an API with an updated-since cursor, or receiving webhooks on a signed endpoint.
As a target: Calls to your endpoints with a body template, an idempotency key per change, retries with backoff, rate limits, and signed webhook requests.
As a source: Server streams from your services.
As a target: Calls to the methods of your .proto, one per change or streamed, without generated code.
Between systems of the same kind, and across kinds through a transform.
Every committed change in your databases becomes an event on Kafka, Service Bus or RabbitMQ. No outbox tables, no dual writes in the application.
Push changes straight into a CRM, ERP, ticketing system or internal service through its API, when it has no database you may write to.
Keep tables, documents, graph nodes or search entries current from a topic or queue, with older events never overwriting newer ones.
Bring the data of SaaS and internal applications into Databricks or Snowflake through their APIs or webhooks.
Bridge Kafka to Azure Service Bus or RabbitMQ to Event Hubs, across clouds or during a migration, keeping the order per record.
Turn events into search entries and embeddings as they arrive.
Give every team a stream of business events from the systems of record, without changing those systems.
Keep ERP, CRM and finance applications in step with each other, through their APIs and your enterprise broker.
Tell caches and read models exactly which records changed, the moment they change.
Notify customers and colleagues when an order, a ticket or a shipment changes, from the database itself.
Bring device events from MQTT or NATS into databases and the lakehouse, and send changes back to the edge.
Move from one broker or cloud to another while producers and consumers keep running.
The record's group becomes the partition key, session, message group or ordering key, so its changes arrive in order.
Every event carries the change's version, so a consumer can ignore older changes with one comparison.
The same change always has the same idempotency key or deduplication id, so retries create no duplicates.
Timeouts, throttling and server errors are retried with backoff; rejected calls wait in the dead-letter queue with the response.
Operational, reporting and analytical SQL databases, from PostgreSQL to the lakehouse.
ExploreDocument, key-value and wide-column stores: MongoDB and its relatives, DynamoDB, Firestore and Cassandra.
ExploreProperty graphs in Neo4j and Neptune, and graphs kept inside PostgreSQL, MongoDB, SQL Server and Oracle.
ExploreSearch engines and vector stores that serve search, recommendations and AI assistants.
ExploreWant to discuss your use case? Write to info@aestus-cdc.com.