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

Connection Request — Idempotent Flow

The requirement's own example: a retried POST /connections must never create a second invitation.

Editable source SVG draw.io All views
Member A API layer Anti-abuse Graph service Edge store Kafka ATC Member B 1. POST /connections + key 2. invite rate + risk 3. allow 4. create invitation 5. insert if key unseen 6. created: pending 7. InvitationSent 8. 201 invitation 9. 201 Created 10. retry, same key 11. same 201, no new row 12. invite event 13. push + in-app 14. accept 15. accept invitation 16. CAS pending to connected 17. ConnectionCreated Connection Request — Idempotent Flow One row keyed by the ordered member pair makes accept a single compare-and-set; adjacency lists are derived. v 1.0 · owner Graph Engineering · date 2026-09

Decisions

  • POST /connections takes an Idempotency-Key. The key is stored with the row, so a retry returns the original result
  • The edge is one row keyed by the ordered member pair; accepting is a compare-and-set from pending to connected
  • Graph serving in LIquid is derived from the edge log, so the write path never waits on the graph index

Consistency

  • Connection state is strongly consistent in the edge store. LIquid is eventually consistent, seconds behind
  • For the first minutes after a change, authorization checks for the two members involved read the edge store (read-your-writes); everyone else reads LIquid

Abuse controls

  • Invitation rate limits and a spam score run before the write
  • Weekly invitation caps are a product rule enforced here, not in the client
◀  Feed Ranking Pipeline All views Message Delivery — Ordered, Online and Offline  ▶
Solution Architecture v1.0 · LinkedIn's own stack in LinkedIn-run colos · Enterprise Architecture · 2026-0917-connection-request-sequence