以下詳細指南及說明性範例以英語提供。所有範例業務紀錄均為虛構。
Where Hermes (Allegro) fits
Assessing Allegro’s Kafka-based publish/subscribe system for an event architecture.
When to choose another approach
This specifically means Allegro Hermes. It is an architecture option, not a ready-made connector or a no-loss/throughput promise.
Worked example and evidence
Fictional order service: publish an event, deliver to a stock subscriber and record failures for review. A repeated event ID cannot reserve stock twice.
What you need to supply
Broker/Hermes versions, topic contracts, subscriber owners, delivery policy and replay needs.
What acceptance should demonstrate
Demonstrate duplication, unavailable subscribers, retry expiry and replay with traceable event IDs.
Running costs and responsibilities
Assign hosting, upgrades, retention, failed-message review and incident response.
Technical scope to confirm
Confirm deployment-specific delivery semantics and retries against versioned documentation.
A proposal should identify the systems and data, direction of sync, access feasibility, failure handling, named owners and included deliverables. Listing this technology does not imply a prebuilt connector, vendor partnership or included feature.
How are duplicate or failed messages handled?
Consumers need idempotency. Scope retries, expiry and manual recovery together, including when retention expiry makes recovery impossible.