there's a lot interesting possibilities for you can handle this. for our sync engine at sunsama we've tried a few different approaches.
currently, we store the "parent" recurring event as one document. then we store exception events as standalone one off calendar events that link back to the parent recurring event. unfortunately, we have to maintain two different types of exploded versions of recurring events (to handle notes on an instance).
eventually, we added a bunch of extra fields to the parent event like a pointer to the next upcoming instance of this event and denormalized full list of exceptions so that we can more easily handle application logic like sending out reminders, and letting you use arrows to navigate b/w instance s of recurring events.
so far with this approach of separating out the parents and children we've run into very few problems.
currently, we store the "parent" recurring event as one document. then we store exception events as standalone one off calendar events that link back to the parent recurring event. unfortunately, we have to maintain two different types of exploded versions of recurring events (to handle notes on an instance).
eventually, we added a bunch of extra fields to the parent event like a pointer to the next upcoming instance of this event and denormalized full list of exceptions so that we can more easily handle application logic like sending out reminders, and letting you use arrows to navigate b/w instance s of recurring events.
so far with this approach of separating out the parents and children we've run into very few problems.