Explain Low-Latency Linux Networking and Shared-Memory Trade-Offs

## Interview Prompt Explain TCP congestion control, the Nagle algorithm and `TCP_NODELAY`, Linux process scheduling, shared memory, and kernel-bypass networking such as DPDK. Compare a kernel-bypass approach with an accelerated socket stack and describe the operational pitfalls you would expect in a low-latency trading service. ### Constraints & Assumptions - Separate network congestion control from local packet batching and application buffering. - Assume latency matters, but correctness and bounded tail behavior matter more than one benchmark number. - Address CPU affinity, NUMA, memory ownership, and observability. ### Clarifying Questions to Ask - Is traffic small-message request/response, bulk transfer, or market-data multicast? - Can the application dedicate cores and NIC queues? - Must the service preserve the standard sockets API? ### What a Strong Answer Covers - Accurate congestion-window and acknowledgement feedback at a conceptual level. - Nagle's small-write coalescing and the latency/packet-rate trade-off of disabling it. - Scheduler, affinity, context-switch, shared-memory synchronization, and cache-coherence effects. - Kernel bypass as user-space packet processing with explicit queue, memory, and polling ownership. - Comparison with accelerated sockets plus failure handling, monitoring, and safe fallback. ### Follow-up Questions - When can `TCP_NODELAY` make throughput or congestion behavior worse? - How would you detect a NUMA placement regression? - What functionality must an application replace when bypassing the kernel network stack?