ⓘ Hover over any item to see detailed technical information

📅
Google Calendar — Logical Data Architecture
Behavioral model of how Calendar stores events, attendees, and recurrence
🗓
Calendar Object Model
Calendars as buckets of events
Calendar as Collection
A named bucket, not a schedule
Calendar as Collection
A Google Calendar is a named collection (bucket) of events identified by a unique calendar ID. Users can own multiple calendars and subscribe to shared or public calendars. The primary calendar has an ID matching the user's email address.
  • Each calendar has a unique calendarId
  • Primary calendar ID = user email
  • Secondary calendars have random ID strings
  • Events belong to one calendar only
Unique Event ID
Immutable key per event instance
Unique Event ID
Each event has a unique, immutable ID (a random string or iCalUID). The Calendar API references events by calendarId + eventId. The iCalUID is a standards-compliant identifier used for interoperability with other calendar systems (RFC 5545).
  • eventId: Calendar API-specific ID
  • iCalUID: RFC 5545 compatible UID
  • Both persist across updates and moves
  • Used for federation with Exchange/Outlook
Event Data Model
Flat object with structured fields
Event Data Model
An event is a flat object in the calendar store. Key fields: summary, description, location, start/end (dateTime or date), status (confirmed/tentative/cancelled), visibility (default/public/private/confidential), attendees array, recurrence array, conferenceData.
  • Start/end support timezone-aware dateTimes
  • All-day events use date (not dateTime)
  • Extended properties for custom metadata
  • conferenceData links to Meet/Zoom
🔁
Recurrence Model
RRULE-based recurring events
RRULE Storage
Single master event, not N copies
RRULE Storage
Recurring events are stored as a single "master" event object with an RRULE string (RFC 5545 format, e.g., RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR). Individual instances are generated on-the-fly when the calendar view is rendered — they are not stored as separate event objects.
  • 1 stored object, N virtual instances
  • Instances computed at query time
  • RRULE/RDATE/EXDATE all supported
  • Changes to master update all future instances
Exception Instances
Modified occurrences are stored separately
Exception Instances
When a single occurrence of a recurring event is edited ("this event only"), Calendar creates a new event object called an "exception instance." This instance has a recurringEventId linking it back to the master and an originalStartTime identifying which occurrence it overrides.
  • Stored as separate event objects
  • recurringEventId → master event
  • originalStartTime = occurrence it replaces
  • EXDATE added to master to skip original
👥
Attendee & RSVP Model
Invitation and response storage
Attendees Array
Stored on the organizer's event object
Attendees Array
The attendees list is stored as an array of objects on the event. Each attendee entry contains: email, displayName (optional), organizer (bool), self (bool), responseStatus (needsAction/accepted/declined/tentative), optional (bool), and resource (bool for room resources).
  • All RSVP state stored on organizer's event copy
  • responseStatus updated per attendee
  • Guest list visibility controlled by guestsCanSeeOtherGuests
  • Max ~1,000 attendees per event
Attendee Copies
Each attendee has their own event copy
Attendee Event Copies
When an event is sent to attendees, Calendar creates a copy of the event on each attendee's primary calendar. The attendee's copy is linked to the organizer's event via iCalUID. This means event changes by the organizer must propagate to all attendee copies.
  • N attendee copies stored separately
  • Linked via shared iCalUID
  • Attendee can move copy to another calendar
  • Organizer updates propagate via CalDAV/internal sync
🔗
Calendar Sharing & Subscriptions
Access control and federation
Calendar ACLs
freeBusyReader / reader / writer / owner
Calendar ACLs
Calendar sharing is managed via ACL rules (acl.list / acl.insert API). Roles: freeBusyReader (see only busy/free), reader (see event details), writer (create/edit events), owner (full control including ACL management). ACLs can target users, groups, domain, or public.
  • ACLs on the calendar object, not individual events
  • Event visibility field can override (private events)
  • Domain-wide sharing via Workspace Admin
  • Resource calendars (rooms) use same ACL model
External Subscriptions
iCal feed subscriptions (read-only)
External Subscriptions
Users can subscribe to external calendars via iCal URL. These are fetched periodically (typically every 12–24 hours) and cached in Google's infrastructure. Subscribed calendars appear as read-only calendar objects in the user's calendar list.
  • Cached copy, not real-time sync
  • Update frequency controlled by Google
  • No write access on subscribed calendars
  • Supports Webcal:// and HTTPS iCal URLs
Event Creation & Invite Flow
Organizer Creates
Event object created
→
RRULE Parsed
If recurring event
→
Invite Sent
Email notification
→
Attendee Copy
Created on their calendar
→
RSVP Captured
responseStatus updated
→
Propagated
Changes sync via iCalUID
💬
Google Chat — Logical Data Architecture
Behavioral model of how Chat stores messages, spaces, and threads
🏛
Space Object Model
The top-level container for messages
Spaces as Collections
DMs and rooms are both Spaces
Spaces as Collections
In Google Chat's data model, everything — Direct Messages, Group DMs, and named Spaces (rooms) — is stored as a Space object with a unique space name (ID). The type field distinguishes: DIRECT_MESSAGE, GROUP_CHAT, SPACE.
  • All types share the same Space schema
  • Space name = persistent unique ID
  • DMs: 1:1, always two members
  • Group chats: 3+ members, no display name
Space Membership
Member records per space
Space Membership
Each space has a membership list stored as separate member objects. Members can be users, Google Groups, or Chat apps/bots. Membership has a role: ROLE_MEMBER or ROLE_MANAGER. Members can join, leave, or be added/removed by managers.
  • Stored as membership objects, not user properties
  • role: ROLE_MEMBER or ROLE_MANAGER
  • Apps/bots also stored as members
  • Membership changes logged in space history
💬
Message Model
Flat message objects per space
Message Object
Flat store within space boundary
Message Object
Messages are stored as flat objects within a space. Each message has a name (ID), sender, createTime, text, and optionally thread reference, attachments, cards, annotations, and reactions. Messages are immutable after creation unless edited.
  • Name = spaces/{space}/messages/{message}
  • Thread reference optional (threaded spaces)
  • Supports Google Cards v2 for rich content
  • Edit history tracked via lastUpdateTime
Threading Model
Reply chains stored as thread objects
Threading Model
In threaded Spaces, messages can belong to a thread. A thread is a sub-collection within a space. Thread membership is tracked via the message's thread field (thread name reference). The thread object stores its own name and reply count metadata.
  • Thread name = spaces/{space}/threads/{thread}
  • Messages declare their thread parent
  • DMs and Group Chats: no threading
  • Threaded mode: optional per-space setting
Reactions & Annotations
Stored as message child objects
Reactions & Annotations
Emoji reactions are stored as reaction objects associated with the message. Annotations (mentions, slash commands, rich link previews) are stored as structured annotation objects within the message body. These are first-class data, not embedded text.
  • Reactions: emoji + user identifier
  • Mentions: USER_MENTION annotation type
  • Link previews: SLASH_COMMAND annotation type
  • Annotations discoverable via Chat API
📎
Attachments & Drive Integration
File references within messages
Drive File References
Links to Drive objects, not copies
Drive File References
When a user shares a Drive file in Chat, the message stores a reference (Drive file ID) — not a copy of the content. The file remains in Drive, and the Chat attachment provides a preview and access link. Permissions are governed by Drive ACLs, not Chat membership.
  • No content duplication into Chat store
  • Access governed by Drive permissions
  • Preview generated at message display time
  • Deleting Drive file breaks Chat preview link
Inline Attachments
Uploaded directly to Chat (images, files)
Inline Attachments
Files uploaded directly to Chat (not via Drive) are stored in Chat's attachment store. These are associated with the message by an attachment name/ID. They may be stored separately from Drive and have different retention characteristics.
  • Stored in Chat attachment store
  • Referenced by attachment name
  • Subject to Chat retention policies
  • Not visible in Drive unless explicitly saved
🏛️
Vault & Retention
Chat history and compliance
History Setting
Per-space history on/off toggle
History Setting
Chat spaces and DMs have a history setting (on or off). When history is off, messages are deleted after 24 hours from the Chat store. Vault can override this for compliance — a Vault hold will retain messages regardless of the history setting.
  • History off = 24-hour message expiry
  • Vault hold overrides history setting
  • Admin can enforce history on via policy
  • History setting visible to all members in DMs
Vault for Chat
eDiscovery and export for messages
Vault for Chat
Google Vault can hold, search, and export Chat messages. Exports include the message text, sender, timestamp, space metadata, and thread structure. Vault searches Chat independently from Gmail — separate matter types and export workflows are required.
  • Separate Vault matter type from Gmail
  • Can target specific spaces or DMs
  • Export format: JSON with metadata
  • Does not export Drive files referenced in Chat
Chat Message Storage Flow
User Sends Message
Client submits to API
→
Space Lookup
Space + membership validated
→
Message Object
Written to space store
→
Thread Assigned
New or existing thread
→
Notify Members
Push to all space members
→
Vault Check
Hold / retention eval
Legend
Calendar: event objects
Calendar: recurrence model
Calendar: attendees / RSVP
Calendar: sharing / ACLs
Chat: spaces model
Chat: message model
Chat: attachments
Chat: Vault / retention

Architecture Documentation Notes

Calendar: RRULE Insight

A recurring meeting with 365 instances does not create 365 event records. One master event with an RRULE is stored. Exception instances (edited occurrences) do generate separate records. This is critical for migration planning — tools must handle RRULE expansion and exception re-attachment.

Calendar: Attendee Copies

Event updates from the organizer propagate to attendee calendar copies via CalDAV-style sync (for external attendees) or internal propagation (for Workspace users). During tenant migration, attendee event copies must be re-linked to the migrated organizer's calendar.

Chat: History is Mutable

Chat's history on/off setting means message persistence is not guaranteed by default. For compliance-conscious organizations, admin policy should enforce history on. Vault holds are the reliable retention mechanism that overrides the history setting.

Source Confidence

Calendar RRULE storage, attendee model, ACL model: documented in Google Calendar API v3. Chat space/message/thread model: documented in Google Chat API. Vault behavior: documented in Google Vault Help Center and API docs. Underlying infrastructure details not publicly disclosed.