设计calendar

面试中经常遇到这个日历设计问题，讨论一些api design，里面的time slot可以link一些event，有的event是一次性的，也可以是每周一次 host可以在calendar上发表活动，要支持添加查找修改删除单次或者可重复的预约
Overview
1. View my schedule for next week, next month or next year(read)
Event:
1. Participants and status


Create event:
1. Set visibility(write)
2. Add guest(write)
3. Add zoom(write)

4. Set recurring frequency / schedule(write)

Requirements:
1. Create and send an event
2. Receive an event

3 visibility
System requirements:
. Reliable
. consistent

Traffic:
1. 1M, create 1 event / day,  receive 3 event/ day
2. Storage: 10 ^ 5 * 100 * 365 day * 5 = 15GB; (300 ~ 1k)
3. QPS: write  10 ^ 5 * 1 / (24 * 3600) = 2 k
4. Read : 2 k * 10 = 20 k/ s; (comment)

对于日历来说，我们的availability 不是说参与者能不能收到相同的消息。而是说 user在使用app的时候，是否能有极高的概率可以获得一个有效response。 一个比方就是我随便打开app的时候，app会返回一个日历给我。 10000k 个人随便打开日历的时候，他们的app也应该返回一个有效日历（可能有几秒钟落后于最新的日历）。即使这期间有人在他们的日历上加event。
Consistency在这里更多是说，我在写 （create or update）完后，user是不是能 瞬间读到最新的update/event。 这里的代价就是，如果我的 ”写“ 操作没有完成，用户在这个短暂interval里，是无法获得日历的。选择牺牲 Consistency的话，不是说user在读的时候很久都看不到最新的，而是eventually consistency。 对于日历这种app， eventually consistency已经足够，这个app不是股票那种时间敏感的，你的更新晚了三秒才被人看到并没有影响。  选A并不是说会有很低的Consistency。 只是eventually consistency。 大多数时间不敏感app， eventually consistency 足矣。而用户随时可以看到自己的日历才是最重要的。
以上只是说我认为A比C好。 但是面试的时候，只有言之成理，选A or C都应该可以，但是要说明白为啥。

选Consistency是指的among all users。如果想要cancel一个event，希望所有参与者的这个event都被cancel；如果modify一个event，也希望所有参与者这个event都被modify。Inconsistency会造成一部分user的event被modify/cancel，但是另一部分没变。
参考链接

https://docs.google.com/document ... bc0mUi8sLt3g30/edit

接下来某个youtube中老印讲的，就截屏下来