LinkedIn Professional Network · View 07 of 30 · 3 · Structure
Rules
- Clients reach services only through the API layer; services reach stores only through their own Rest.li resources
- The serving layer holds only derived data. Any of it can be dropped and rebuilt from the log or the lake
- The one upward arrow is derived data being pushed into serving stores; no request path goes up
Why it is layered this way
- Keeping derived serving separate from systems of record is LinkedIn's central data idea. Venice, LIquid, FollowFeed and Galene are rebuildable, so they are sized for read speed rather than durability
- Platform services (D2, Helix, T-REX) cut across every layer and carry no business logic
Risks
- A service that reads another service's store directly bypasses its privacy checks. The ACL service forbids it; convention alone would not
- A derived store rebuilt from a bad push serves wrong data quickly. Venice keeps the previous version so it can be swapped back
