The Application Communication Lens

Track boundaries — what this reference owns

This track is the application-layer communication guide: protocols, API contracts, and data-movement patterns between processes. It builds on sibling tracks and does not re-teach their material.

Sibling track	They own	This track adds
Networking	TCP/UDP, DNS, TLS, HTTP/1–3 framing, L4/L7 LB, CDN cache headers	What you put on the wire: REST vs gRPC vs events, resource design, serialization, WebSockets/WebRTC at app level
Concurrency	Threads, locks, semaphores, deadlocks, atomics, in-process event loops	Timeouts/retries at call sites, API rate limits, bounded outbound connection pools, backpressure between services
Distributed Systems	CAP, replication, consensus, Kafka partitions, delivery semantics, sagas/outbox correctness	Choosing sync vs async integration, webhooks, AsyncAPI contracts, when to use a broker vs HTTP callback
Databases	B-trees, MVCC, sharding, Parquet/lake storage formats	Presigned upload URLs, export-job APIs, orchestrating landing in object storage — not how S3 or WAL works internally
Data Engineering	Spark/Flink pipelines, CDC implementation, medallion transforms	Async bulk-export API surface, webhook-on-complete after ingest lands — not how the pipeline runs
LLD	Class APIs, SOLID, design patterns, rate limiter as an object	HTTP/GraphQL/gRPC as system-level protocols, OpenAPI, pagination — not ParkingLot method signatures
Microservices	Decomposition, discovery, gateway, mesh, CQRS/ES	Wire protocols (REST/gRPC) — Communication; consensus — Distributed Systems
Observability	Logs, metrics, OTel SDKs, SLOs, sampling	traceparent / gRPC metadata propagation across API hops — not how to build dashboards
Security	AuthN/AuthZ, OWASP, XSS/CSRF, API hardening, PII, SDLC	TLS wire details — Networking; mesh mTLS ops — Microservices
OS	Processes, scheduling, containers, file I/O	Only where it surfaces in comms: FD limits on WebSocket fleets — skim, don't duplicate

Read order: Networking first (required). Concurrency and Databases help for backpressure and bulk-transfer context. Distributed Systems after Topics 1–7 here — messaging depth assumes you already picked how services should talk.

What this topic owns (vs Networking)

Networking covers the wire: TCP reliability, DNS resolution, TLS handshakes, HTTP/1–3 framing, load balancers, CDN caching headers. This track covers what you put on the wire and why — API styles, contracts, serialization, real-time protocols, and moving gigabytes to terabytes.

Senior signal: you can trace a user action from client → API gateway → service mesh → downstream RPC without re-explaining TCP.

Communication styles (memorize the trade-off table)

Style	Coupling	Discovery	Typical latency	Failure visibility
Sync RPC/REST	Tight (caller waits)	Direct address or service discovery	Low–medium	Immediate to caller
Async messaging	Loose (temporal decoupling)	Broker/topic	Higher (queued)	Delayed; needs DLQ
Streaming	Medium	Long-lived connection	Low for push	Connection state matters
Shared DB/file	Very tight (anti-pattern at scale)	Schema coupling	Varies	Hidden, dangerous

REST is an architectural style, not "JSON over HTTP"

Fielding's constraints: client-server, stateless, cacheable, uniform interface (resources identified by URIs, manipulation via representations, hypermedia optional), layered system, code-on-demand (optional).

Interview trap: "RESTful" APIs that are really RPC with HTTP verbs (POST /createUser, GET /getUserById/42). Know when that's fine (pragmatism) vs when resource modeling matters (public APIs, long-lived contracts).

RPC mental model

Remote Procedure Call: client calls getUser(id) as if local. gRPC, Thrift, tRPC are modern RPC. Trade-offs vs REST:

• Pros: Strong typing, codegen, efficient binary payloads, bidirectional streaming built in.
• Cons: Browser support weaker (needs gRPC-Web or proxy), harder to cache at CDN, tighter coupling to generated stubs.

Coupling dimensions (staff-level vocabulary)

1. Temporal — must both sides be up at the same instant?
2. Location — does caller know callee's host/port?
3. Schema — can one side evolve without breaking the other?
4. Semantic — does caller understand callee's domain model?

Loose coupling → async events + schema evolution rules. Tight coupling → sync RPC with versioned protobuf.

Idempotency at the boundary

Networking introduced HTTP idempotency (GET/PUT/DELETE vs POST). At the application layer:

• Idempotency keys — client sends Idempotency-Key: uuid on POST; server dedupes within TTL.
• Natural idempotency — PUT with full resource state, DELETE by ID.
• Retries — only safe with idempotent operations or keys; otherwise duplicate charges, duplicate orders.

Choosing a protocol (decision tree sketch)

Need browser-native + cacheable public API? → REST/JSON (+ OpenAPI) Need typed internal microservice mesh? → gRPC or Connect Need flexible client-driven queries? → GraphQL (+ BFF) Need server push to browser? → WebSocket or SSE Need peer media (video, P2P file)? → WebRTC Need TB-scale bulk move? → Object storage + multipart / physical transfer Need durable async between teams? → Message broker (see Distributed Systems)

Cross-reference: Distributed Systems → Messaging & Streams for Kafka semantics, consumer groups, and exactly-once — not duplicated here. LLD → API & Component Design covers in-process public surfaces; this track covers cross-network contracts.