微服务的事件通知里，如何设计事件

RT。

背景： 需要设计一个微服务的事件通知，通知会发送到 Kafka，其他感兴趣的微服务自动消费。当前各个微服务可以通过 RPC，或者 REST 调用，或者直接访问 DB 获取数据（有些可能有限制）。

想法是把这个事件设计的尽量简单，但是不知道需要考虑哪几个方面，请大神指教。

自身考虑的几个点是：

1. 如果允许通过唯一标识拿到最新的数据，是不是只需要事件包含三个基本信息就行：唯一标识、操作类型和出发事件；
2. 如果考虑服务之间尽量少调用（或者说减少数据库的 QPS ），在事件里包含了尽量多的信息，譬如更新，包含更新了哪个字段，什么值这类。为了做到尽量简单，那么在前期只能说综合已有业务考虑，把需要的字段都加进来。

现在组里的大佬是倾向于第一种，但是这种应该需要通过唯一标识拿一次详细数据（不管是 RPC、RESTful 还是数据库直接查），都会对服务方或者数据库产生压力，不确定这种方式是否最优。

不知对于这种事件的设计是从哪几个方面考虑的？我自己的考虑有什么问题？请大佬不吝赐教。