咨询两种Pub/Sub架构的通用命名:推送数据型与通知查询型
Great question! These two common Pub/Sub patterns have widely recognized names in event-driven and distributed systems design. Let’s break them down clearly:
1. Event-Carried State Transfer (ECST)
This is exactly the pattern you described where the publisher sends a message containing all the updated state or full change details directly via Pub/Sub. Subscribers can update their local caches or state without needing to call back to the database at all.
- Pros: Cuts down on extra round-trips to the database, lowers latency for subscribers, and works well if subscribers don’t have direct access to the source DB.
- Cons: As you pointed out, it’s fragile for order-sensitive changes—out-of-order messages can leave subscribers with inconsistent local state. You also have to handle duplicate messages carefully (to avoid re-applying stale updates) and ensure the message payload stays aligned with what subscribers actually need.
2. Event Notification (or Notification-Only Pattern)
This matches your "Notification-and-check" approach: the publisher sends a minimal signal (often just an entity ID or a simple flag that a change occurred), and subscribers are responsible for fetching the latest, complete state directly from the database themselves.
- Pros: Extremely robust for order-sensitive scenarios. No matter the order of notification delivery, subscribers always pull the most up-to-date state from the source of truth. It also keeps message payloads small, avoids data duplication across events, and eliminates the risk of sending outdated or incomplete data in messages.
- Cons: Adds an extra database read per notification, which could increase load on your DB if you have high event volume. It also introduces slightly more latency due to the additional fetch step.
Quick Tradeoff Recap
- Use ECST when you need low latency, subscribers can’t access the DB, or the changes are simple and order-insensitive.
- Use Event Notification when data consistency is critical, changes rely on strict order, or you want a more fault-tolerant setup (even if it means a small performance hit).
内容的提问来源于stack exchange,提问作者bhh1988

