LinkedIn·Software Engineer·Onsite - System Design / Architecture·Senior

Senior

May 2026

Summary

LinkedIn system design round for a software engineer role. The whole session was basically one big question about designing a calendar service, which sounds manageable until you realize how many rabbit holes it opens up.

Questions Asked (1)

Design a calendar service that supports creating, reading, updating, and deleting events with fields like title, start/end times, attendees, and location. The system should handle conflict detection per attendee, recurring events, time zone correctness, invitations and RSVPs, and free/busy queries. It needs to scale to hundreds of millions of users with low-latency reads and reliable notifications.

System DesignData ModelingTechnical Trade-offs

Author's notes

This question is basically five questions dressed up as one.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a high-level architecture that separates event storage, conflict detection, and notification services. Focus on data modeling for recurring events and time zones, and discuss trade-offs between consistency and latency for conflict detection and free/busy queries.

Pro tip: Emphasize that conflict detection should be optimistic and asynchronous for most cases, but provide strong consistency for critical updates via a lightweight locking mechanism per attendee. Also, mention that recurring events should be stored as a rule (e.g., RRULE) with exceptions, not as individual instances, to avoid storage explosion.

1. Clarify Requirements and Scale

Ask about expected read/write ratio, latency requirements, consistency needs, and features like recurring events and time zones. Confirm scale: hundreds of millions of users, billions of events.

2. High-Level Architecture

Propose a microservices architecture with separate services for event CRUD, conflict detection, notification, and free/busy. Use a distributed database like Cassandra or Spanner for events, and a cache like Redis for low-latency reads.

3. Data Modeling and Time Zones

Design event schema with fields: event_id, title, start/end (UTC), timezone, attendees, location, recurrence rule, exceptions. Store times in UTC and convert to user's timezone on read. Use RRULE for recurring events.

4. Conflict Detection and Free/Busy

For conflict detection, maintain an index of attendee_id -> busy intervals. Use optimistic concurrency with versioning; for strong consistency, use per-attendee locks. For free/busy queries, precompute and cache busy intervals per user.

5. Invitations, RSVPs, and Notifications

Use a message queue (e.g., Kafka) to handle invitations and RSVPs asynchronously. Ensure reliable notifications with retries and dead-letter queues. Consider push notifications and email.

Key Points to Mention

Use UTC for storage and convert to local time zones on read to handle time zone correctness.
Model recurring events with RRULE and exceptions to avoid storing individual instances.
Implement conflict detection with optimistic concurrency and per-attendee locks for strong consistency when needed.
Precompute and cache free/busy intervals for low-latency queries.
Use asynchronous processing with message queues for invitations, RSVPs, and notifications to ensure reliability and scalability.
Consider sharding by user_id or event_id to scale horizontally, and use a distributed database like Cassandra for high write throughput.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.