Lagom：Read Side Processor与Broker Api构建读模型的优劣对比

Great question! Let’s break down the core tradeoffs between these two approaches for building read models in Lagom, focusing on their unique strengths (we’ll exclude Cassandra/Jdbc-specific offset tracking implementations as requested):

Advantages of Read Side Processor #

• Deep persistence layer integration: It’s tightly coupled with Lagom’s event-sourced entities, meaning you don’t need extra routing or configuration to connect to your service’s event stream. This makes it ideal for read models that are directly tied to a specific service’s domain events.
• Out-of-the-box exactly-once processing: Even without Cassandra/Jdbc offset storage, the Read Side Processor’s design centers around persistent offset tracking (you can use other storage backends too). This guarantees each event is processed exactly once, eliminating duplicate updates to your read model—critical for scenarios where data consistency is non-negotiable.
• Built-in resilience tools: It comes with ready-to-use backpressure and retry logic. If your read model update fails (e.g., a database connection blip), the processor will automatically retry without you having to implement custom error-handling code, boosting system stability.
• Targeted event filtering: You can directly specify which event types to process within the processor itself. This keeps your read model logic focused and avoids the need for external topic filtering in a broker.

Advantages of Broker API #

• Lower end-to-end latency: As you noticed in your prototype, this is a big one. The Broker API uses a push-based pub/sub model—events are sent to the broker immediately after being persisted, and read model services consume them in real time. In contrast, Read Side Processors often use a polling or batch-fetch approach to pull events from the journal, which adds inherent latency.
• Full architectural decoupling: Read model services don’t need to be tied to the event-sourced service’s persistence layer. They can be deployed independently, scaled separately, or even built with different tech stacks entirely. This flexibility is perfect for microservices architectures where loose coupling is a priority.
• Multi-consumer support: A single event topic can be consumed by multiple read model services. You don’t need to create a separate Read Side Processor for each read model, which simplifies setup when building multiple independent views of your data.
• Better scalability for high throughput: Brokers (like Kafka, which Lagom integrates with) are built for horizontal scaling. You can easily add more consumer instances to handle high-volume event streams, whereas Read Side Processor scaling is more constrained by the journal’s pull mechanism.

Why You Saw Higher Latency with Read Side Processor #

Your observation is totally expected! Read Side Processors rely on periodically checking the journal for new events (or fetching them in batches), which creates a small delay between when an event is persisted and when it’s processed. The Broker API skips this step by pushing events immediately, so the read model gets updated faster.

内容的提问来源于stack exchange，提问作者Teimuraz