Hacker News Reader

Comment by pphysch | Hacker News Reader

If you are using "trigger events" for security reasons, wouldn't it be more appropriate to send an ephemeral "eventID" rather than an actual "orderID"? Otherwise you may be leaking order IDs, which could potentially carry useful information for an attacker.

View on HN

Any exposed information should be exposed deliberately. Although I didn't cover it in this post. In my event-driven setups, events are always wrapped in a message envelope data structure. Where a message is contains 1) the event/payload and 2) a set of headers to carry more "system-y" data, like time of recording, system of origin, and other observability related information. The event ID is one of those values.

In general you need to send something which can be used to look up the data in a more appropriate (e.g. authenticated or deletable) system. A true event ID may not be available until after the message is successfully produced; anything generated before that is tantamount to the order ID anyway.

Note that "sensitive" in this case can mean a persistence/retention boundary and not a security boundary.

Shouldn't there be an eventID regardless of type?

It may be useless overhead in a high performance system (e.g. game engine) but is probably mandatory for distributed systems.

I'm not sure. We have distributed systems of this type at $JOB and a correlation ID that is generated on user action and attached to every event in the chain (regardless of service) is plenty. I don't think we've ever needed to look at anything so specifically that a unique event ID for each event would have been helpful.

You also get event IDs "for free" with lots of systems, e.g. Kafka topic/partition/offset is more than sufficient as a unique global ID for later use.

Reply on news.ycombinator.com