The System Design Round

The round format confirmed

From Blind + Glassdoor reports: round 3 is system design about their system — "how external apps can be triggered by an action on the table, with emphasis on event-driven architecture and failure tolerance."

• Domain-specific, not generic. It's monday's automations/integrations ("when status changes → notify Slack / call a webhook / move item"), not "design YouTube."
• They grade tradeoffs & thought process, not a perfect diagram. Break it down, weigh options, communicate.
• Failure tolerance is the recurring theme. Expect: "what if a worker dies mid-task? what if the external API returns 500? what if the queue is down?" Have an answer for each.

Design framework

Verbalize these beats so the interviewer can follow. Score 2× for leading with failure modes before they ask.

Automations / external triggers ★ confirmed

The prompt: "How can external apps be triggered by an action on the table?" Build the engine that runs "when X happens, do Y" reliably.

Other questions — plausible, not confirmed my inference

Be honest with yourself about these. After deep research, the automations question above is the only system design prompt that appears in candidate reports. The three below are not in any report — they're the systems monday would plausibly pick from their own product, each chosen because it exercises a different muscle. Prep them as insurance, not as predictions. (Two things you might expect here are deliberately absent: "notify users" is a coding question you've already done, and "board ordering" is the E2E question you've seen.)

Activity feed / Notifications tab plausible

monday's Notifications tab is a single feed across all boards: items assigned to you, @mentions, updates on items you follow, status changes. Classic fan-out design — the most likely "real" system design pick if they go beyond automations.

feed_entries  (user_id, event_id, type, source_ref, created_at, read_at)  // per-user, push
follows       (user_id, target_type, target_id)        // item/board subscriptions
events        (id, account_id, type, actor_id, payload, created_at)  // the source log, pull

Real-time collaborative editing plausible

Multiple users editing the same board at once — cells, item names, long-text. The deepest algorithm discussion, and a direct extension of the cell-change concurrency from your E2E prep.

Search across boards plausible

Typeahead search over every item the user can see, sub-200ms. Ties back to the EAV problem — JSON column values aren't SQL-queryable, so search and filtering both go through the same index.

Failure tolerance — the patterns they grade

monday explicitly grades this. Memorize the five patterns and when each applies.

The questions they WILL ask — have the answer ready

• "What if a worker dies mid-task?" → Lease expires, task is re-claimed by another worker. Idempotency key means re-running is safe.
• "What if the external API returns 500?" → Retry with backoff; after N fails → DLQ + alert. Per-integration circuit breaker so one bad endpoint doesn't burn workers.
• "What if the queue is down?" → Producers buffer locally / the event bus (Kafka) is the durable log; consumers resume from offset on recovery. No events lost.
• "What if the same event is delivered twice?" → Idempotency key dedups; the action runs once.
• "What if a slow integration backs up?" → Per-action-type queues isolate it; autoscale that pool; the fast integrations are unaffected.

Real-time board updates

The cross-over with E2E. If they steer toward "how do all viewers see a change live," this is the answer — and it shares the same event bus as automations.

• Channel per board (board:{id}). Subscribe on board open; verify permission on subscribe.
• Broadcast deltas, not full boards.
• Catch-up after disconnect: client reconnects with last_event_id; server replays missed events from a Redis stream or the DB.
• Conflict resolution: last-write-wins per cell for scalars; set-union for collections (the people-column story from E2E).
• Connection scale: 100k+ concurrent → stateless WS servers + shared Redis; a broker library (Centrifugo / Socket.IO adapter) handles fan-out.

Webhook delivery sub-topic of automations

"External apps triggered by table actions" often drills into delivering webhooks to third-party URLs. Not a separate confirmed prompt, but a natural extension of the automations question.

Notification delivery plausible sub-topic

Don't confuse this with the coding round. The notify(IDs, message) dedup algorithm was your coding question — already done. This is the infrastructure side: how a notification, once its recipients are resolved, gets delivered across channels reliably. It's a common automation action and a fair sub-topic, not a standalone confirmed prompt.

Multi-tenancy background

Not a standalone prompt, but the isolation assumption behind everything. Know it cold so you can drop it into any answer.

Phrases that signal senior

Common mistakes

• Direct service-to-service calls. They grade event-driven. Publish events; let consumers react. Don't have the table write call the Slack API directly.
• Claiming exactly-once. Say it's a myth; design at-least-once + idempotent.
• Ignoring failure modes until asked. Lead with them. It's literally what they grade.
• One shared queue for all actions. A slow webhook starves notifications. Per-action-type queues.
• FAANG-scale over-engineering. Kafka + Redis + workers + Postgres is the right palette. No need for exotic stores.
• No idempotency key. Retries + at-least-once delivery without it = double-fired automations. Always key on event id.
• Forgetting cancellation. Scheduled automations can be edited/disabled before they fire — check status before executing.
• Not sizing it. Throw out throughput + worker-count numbers; shows you can reason about scale.