LinkedIn Professional Network  ·  View 20 of 30  ·  5 · Runtime

Notifications — Generate, Decide, Deliver

One service owns the member's attention: it decides whether, when and on which channel they hear about something.

Editable source SVG draw.io All views
Trigger Kafka events graph · content · jobs Generate Concourse content candidates Aggregator Ana and 12 others Decide ATC caps · channel Preferences Espresso Store Notification store Espresso Badge counts Couchbase Retry queue backoff + DLQ Deliver In-app APNs / FCM Email Learn Tracking open · dismiss provider 5xx Notifications — Generate, Decide, Deliver Queue / topic Application we own Decision point Data store External / third party failure / alternate Nothing here is on the path of the action that caused it; a dead pipeline delays alerts, it never fails a post. v 1.0 · owner Notifications Engineering · date 2026-09

Decisions

  • ATC decides for every notification: preferences, frequency caps, deduplication, aggregation and channel (LinkedIn, 2018)
  • Concourse generates content notifications nearline from Kafka (LinkedIn, 2018)
  • No notification step sits on the path of the action that caused it

Numbers

  • Notification created in under 1 s; delivery time depends on the channel
  • Push providers are retried with exponential backoff, then dead-lettered
  • A notification past its usefulness window is dropped, never delivered late

Risks

  • Too many notifications is the fastest way to lose a member. The frequency cap is a member-protection rule with a named owner
  • The badge count is a derived counter and may lag the notification list by seconds
◀  Search — Indexing and Query All views Media — Upload, Process, Deliver  ▶
Solution Architecture v1.0 · LinkedIn's own stack in LinkedIn-run colos · Enterprise Architecture · 2026-0920-notification-pipeline