Streaming & events

An event must not get lost.

An order, a machine state or a stock change is meant to trigger further processes. We design event contracts and implement the platform and connections, so that recipients can respond reliably, including during load spikes or temporary outages.

What we take care of Discuss your project

Event catalog with schemas and owners · Planning and implementation by OTOKO®

Your brief for OTOKO®

What we take care of for you.

An event describes a change that has occurred; a command requests an action. This distinction helps avoid mixing up responsibilities. We define identifiers, timestamp, schema and the required context. Ordering is considered per business-relevant unit, for example a single order, instead of promising a global sequence across the board. For machine connectivity, protocols, network boundaries and permitted interventions are coordinated with the operations owners.

The possible scope of services

Event catalog with schemas in AsyncAPI and a schema registry
Build of Kafka or RabbitMQ clusters with encryption, access control and tenant separation
Connection of sources via Debezium, Kafka Connect and MQTT bridges for machine data
Processing patterns for ordering, idempotency, retries and event sourcing
Operations with monitoring of lag, throughput and consumer groups

We define the specific scope, your involvement and the acceptance criteria before the start.

Technology explained clearly

How we carry out the task.

Plan for duplicate and late messages

Repeated delivery can occur after disruptions. Consumers therefore receive rules for how to recognize already processed events or repeat them without business impact. Late events and subsequent corrections are considered separately. We plan retention, replay and access protection. An event platform is not automatically an immutable archive; retention and deletion requirements must be implemented deliberately. Schema changes are checked for compatibility with existing consumers.

Test backlogs and catch-up processing

Acceptance testing includes a failing consumer, a growing backlog and the controlled restart. Dashboards show delay and errors, not just the number of messages received. To get started, we need event types, expected volumes, maximum delay and the business approach to ordering or duplicate processing.

Meeting room at the OTOKO® Cologne office

A verifiable result

What you keep working with.

Event catalog with schemas and owners
Operational event platform as code
Processing guideline with patterns and examples

The handover brings together implementation and documentation. Together, we review the agreed cases and record any remaining tasks.

Your project in detail

Distribute and evaluate business events reliably.

We develop event-based connections for processes that need to react to changes. In doing so, we plan not only the transport but also the meaning, ordering and reprocessing of the events.

Describe events as business statements

An event states that something has happened, for example a confirmed order. We agree on identifier, timestamp, business context and versioning rules. Consumers must be able to recognize whether they have already processed the same message and whether an event contains enough information for their purpose.

Ordering is often only required within a specific business object. This requirement affects partitioning and parallelism. We avoid blanket promises of a global order or exactly-once business processing, and instead examine the guarantees of the entire chain, including the target system.

Manage backlog, retries and data retention

A slow consumer must not fall further and further behind unnoticed. We monitor delays and plan how capacity is increased or processing is prioritized. Faulty messages get a defined path for resolution, so that a single problematic record does not permanently block all processing.

Repeatable event processing is valuable for repairs and new consumers, but it requires retention and data protection rules. We define which historical events remain available and how the target data set is rebuilt. Acceptance testing explicitly covers interruptions, duplicate delivery and restarting a consumer.

Illustrative project scenario

How the service helps in everyday use.

Example: A confirmed order triggers shipping preparation and a customer notification. Both consumers work independently. If the notification fails, the order is preserved; after restart, the case identifier prevents the same message from being sent multiple times in an uncontrolled way.

This example explains a possible process and is not a customer reference.

Before the first step

Your questions about Streaming & events.

Does a broker guarantee exactly-once processing at the business level?

Not on its own. Platform guarantees apply within certain limits. As soon as external systems are changed, the application must handle duplicate processing and retries appropriately.

Can machine data be connected without direct access to production?

Gateways or existing export paths are often possible. The specific path is reviewed and approved with those responsible for the production environment.

Your project

Which task would you like to solve?

Describe your situation and the desired result. The selected service will be included in the contact request.

Request this service

Navigation

An event must not get lost.