Invitee service 我觉得可以跟 event service 合并了，而且存储的时候 invitee 和 inviter 可以都存一块，变成 User table，就是存每个用户有哪些会的表。
Invitee service和event service分开主要是1）很多invitee Accept/Deny会频繁更新一个event table，所以我想着分开，event table就只存event相关的所有不变信息（面试的时候不考虑改event）2）分开以后就要给invitee加一个startTime和isUpcoming方便排序找到最近要开的会，为了给不同的invitee发notification用，这样其实是redundancy设计所以我当时倾向了nosql。3）同样的原因老师解释的 关于如何设计google calendar - #13，来自 sheboke93 。这样有道理吗？我这么设计会有什么问题吗？
为什么这里要用 SAGA Pattern？
我也觉得Invitee service和event service 可以合并，访问同一个数据库就行了。同一个数据库可以存 Event Table 和 Inviter Table 。
这样也许还可以避免使用SAGA Pattern？
SAGA pattern是为了保证data flow中几个service data consistency。不同flow的顺序不一样，比如create flow用到calendar -> event -> invitee，或者accept/deny flow就不需要request event service。加saga不是必须的，只是提了一下。我想到SAGA的原因是如果中间某一步出错，某些人的event就永远错了。我是觉得涉及到不同service data change而且还有order/dependency，就可以考虑加上。
另外一个数据库存两个table我也没意见，我上面说的意思是不想invitee和event table合并，因为上面说的3点原因。
至于两个service合并，我觉得event service主要负责event info的部分，基本不改变，一个calendar event里面的invitee list是request invitee service得到的。我觉得有3个flow：create，read，modify。其中modify尤其是accept/deny感觉分开invitee service可能更方便。
我还是倾向于合并两个服务，但是数据库层面上同一个数据库并且分表。用户在创建event的时候大多数时候会同时发出 event invite，让客户端 call 两次服务器不太合理。
这里也不需要 SAGA，只要失败时候 retry 应该就可以了。正确性不是绝对的，不是所有分成两步，写两个数据库的服务都要用 SAGA 的，因为保证准确性是会影响性能，增加服务开销的。