Dreambox
Messaging and event-driven systems in Java
We design and build the event pipelines that move data between services reliably and fast: Kafka, ZeroMQ, Netty, Vert.x and WebSocket.
Choosing the transport
There is no single best messaging technology. The choice depends on durability, throughput, latency, fan-out and operational cost.
| Need | Typical fit |
|---|---|
| Durable, replayable event streams | Apache Kafka |
| Very low-latency brokerless messaging | ZeroMQ (JeroMQ in pure Java) |
| Custom TCP protocols and high connection counts | Netty |
| Reactive, event-loop services | Vert.x |
| Live data to browsers and clients | WebSocket (Spring, Netty or Vert.x) |
| In-process fan-out | Local event bus |
What we design
- Ports and adapters: business code depends on a producer / subscriber port; Kafka, local bus and others are adapters.
- Delivery semantics: ordering, partitioning, idempotent consumers, retries and dead-letter handling.
- Back-pressure: bounded queues and explicit overload behaviour instead of silent memory growth.
- Transports: several interchangeable transports (Netty, Vert.x, ZeroMQ) behind one contract.
- Observability: lag, throughput and error metrics in Prometheus.
From our own platform
Our trading platform distributes market data and events through an event-broker module with Kafka and local adapters, and separate Netty, Vert.x and ZeroMQ transport modules. The same patterns apply to non-financial systems with heavy event flow. See also low-latency Java.
Frequently asked questions
Kafka or something lighter?
Kafka is the right backbone for durable, replayable, high-volume event streams between services. For in-process or very low-latency fan-out, an in-memory bus or ZeroMQ is often better. Many systems use both behind one interface.
How do you handle ordering and failures?
We design for it from the start: partition keys, idempotent consumers, retry and dead-letter policies, back-pressure and explicit delivery guarantees per flow.
Can you build real-time streaming to browsers or clients?
Yes. WebSocket and server-push interfaces on Spring, Netty or Vert.x, with reconnection and subscription management.
Do you use ports and adapters for messaging?
Yes, it is our usual approach: producers and consumers depend on a port, and Kafka, local bus or other transports are adapters. It keeps business code transport-independent and testable.
Can you review our existing event architecture?
Yes. See also Java consulting.
More on Java engineering
Tell us about your Java project.
Describe the system, the problem and the team you need. You get a direct reply from an engineer, not a sales queue.