What We’re Building Today

UDP-based log shipperhandling 100K+ logs/second with configurable packet size
Reliability layerimplementing application-level acknowledgments and sequence numbering
Hybrid UDP/TCP fallbacksystem with automatic protocol switching under network degradation
Production monitoringtracking packet loss, throughput, and protocol efficiency metrics

Why This Matters: The TCP Tax at Scale

When Netflix ships millions of playback events per second or Uber processes location updates from millions of drivers, TCP’s reliability guarantees become a performance bottleneck. TCP’s three-way handshake, congestion control, and guaranteed delivery add 40-100ms latency per connection and consume significant server resources managing connection state.

UDP eliminates these overheads, offering 3-5x higher throughput for log shipping workloads where occasional packet loss is acceptable. The trade-off? You inherit responsibility for handling packet loss, ordering, and flow control at the application layer. Today’s implementation demonstrates how companies like Datadog and Splunk achieve massive log ingestion rates while maintaining acceptable reliability through selective UDP usage and intelligent fallback mechanisms.

System Design Deep Dive

Pattern 1: Protocol Selection Strategy

The fundamental architectural decision iswhento use UDP versus TCP. The industry pattern: UDP for high-volume telemetry (metrics, logs, traces) where individual message loss is tolerable, TCP for critical transactional data where guaranteed delivery is non-negotiable.

Trade-off Analysis:

UDP provides 5-10x throughput improvement for small message sizes (<1400 bytes)
Acceptable packet loss threshold: 0.1-1% for metrics/logs, 0% for financial transactions
Network infrastructure consideration: Some enterprise firewalls block UDP, requiring TCP fallback

Anti-pattern:Implementing custom reliability protocols over UDP. Don’t rebuild TCP. If you need guaranteed delivery with ordering, use TCP or a battle-tested protocol like QUIC.

Pattern 2: Application-Level Sequencing

Since UDP doesn’t guarantee ordering, implement sequence numbers at the application layer. This enables:

Gap detectionon the receiver to identify lost packets
Out-of-order bufferingto reconstruct message sequences
Duplicate detectionwhen network paths cause packet replication

Critical insight:Sequence numbers must be monotonic and wrap-safe (use 64-bit integers). Twitter’s engineering team documented a production incident where 32-bit sequence numbers wrapped after 4.2 billion messages, causing duplicate detection to fail spectacularly.

Performance implication:Maintaining ordered buffers for out-of-order packets adds memory overhead. Limit buffer size to prevent memory exhaustion attacks (max 1000 packets or 10MB per connection).

Pattern 3: Adaptive Protocol Switching

Implement runtime protocol switching based on observed network conditions:

IF (packet_loss_rate > 5% over 60s window) THEN switch_to_TCP() backoff_time = min(backoff_time * 2, 300s)ELSE IF (packet_loss_rate< 0.5% AND using_TCP) THEN try_UDP_after(backoff_time)

Why this works:Network conditions are dynamic. A system shipping logs at 4 AM with 0.1% loss might face 8% loss during peak hours when shared infrastructure is saturated. Automatic switching prevents alerting fatigue while maintaining throughput.

Failure mode to avoid:Rapid protocol oscillation (switching every few seconds) creates connection churn. Implement exponential backoff when switching back to UDP: 30s, 60s, 120s, capped at 5 minutes.

Pattern 4: Batching and Framing

UDP’s MTU (Maximum Transmission Unit) is typically 1500 bytes (minus IP/UDP headers = 1472 usable). Pack multiple log events into single UDP packets to amortize per-packet overhead:

Framing strategy:

[4 bytes: batch size][4 bytes: sequence number][2 bytes: message 1 length][message 1 data][2 bytes: message 2 length][message 2 data]...

Trade-off:Larger batches improve network efficiency but increase blast radius of packet loss. One lost 1400-byte packet containing 20 log events loses all 20 messages. Benchmark showed optimal batch size: 10-15 messages per packet for typical 80-byte log events.

Pattern 5: Server-Side Load Shedding

High-throughput UDP servers face a unique challenge: the kernel’s UDP receive buffer can overflow under load, silently dropping packets before your application reads them. Implement explicit load shedding:

Linux tuning:

# Increase UDP receive buffer to 25MBsysctl -w net.core.rmem_max=26214400sysctl -w net.core.rmem_default=26214400

Application-level shedding:Track processing queue depth. When queue exceeds threshold (e.g., 10,000 pending messages), send NACK to client, signaling them to slow down or switch protocols.

Real-world example:Cloudflare’s logging infrastructure processes 10M requests/second. They discovered kernel buffer overflows were their primary packet loss source. Solution: Pre-allocate large buffers and implement backpressure signaling to upstream clients.

","contentEncoded","freeContentEncoded","textContent","What We’re Building TodayUDP-based log shipper handling 100K+ logs/second with configurable packet sizeReliability layer implementing application-level acknowledgments and sequence numberingHybrid UDP/TCP fallback system with automatic protocol switching under network degradationProduction monitoring tracking packet loss, throughput, and protocol efficiency metricsWhy This Matters: The TCP Tax at ScaleWhen Netflix ships millions of playback events per second or Uber processes location updates from millions of drivers, TCP’s reliability guarantees become a performance bottleneck. TCP’s three-way handshake, congestion control, and guaranteed delivery add 40-100ms latency per connection and consume significant server resources managing connection state.UDP eliminates these overheads, offering 3-5x higher throughput for log shipping workloads where occasional packet loss is acceptable. The trade-off? You inherit responsibility for handling packet loss, ordering, and flow control at the application layer. Today’s implementation demonstrates how companies like Datadog and Splunk achieve massive log ingestion rates while maintaining acceptable reliability through selective UDP usage and intelligent fallback mechanisms.System Design Deep DivePattern 1: Protocol Selection StrategyThe fundamental architectural decision is when to use UDP versus TCP. The industry pattern: UDP for high-volume telemetry (metrics, logs, traces) where individual message loss is tolerable, TCP for critical transactional data where guaranteed delivery is non-negotiable.Trade-off Analysis:UDP provides 5-10x throughput improvement for small message sizes (Acceptable packet loss threshold: 0.1-1% for metrics/logs, 0% for financial transactionsNetwork infrastructure consideration: Some enterprise firewalls block UDP, requiring TCP fallbackAnti-pattern: Implementing custom reliability protocols over UDP. Don’t rebuild TCP. If you need guaranteed delivery with ordering, use TCP or a battle-tested protocol like QUIC.Pattern 2: Application-Level SequencingSince UDP doesn’t guarantee ordering, implement sequence numbers at the application layer. This enables:Gap detection on the receiver to identify lost packetsOut-of-order buffering to reconstruct message sequencesDuplicate detection when network paths cause packet replicationCritical insight: Sequence numbers must be monotonic and wrap-safe (use 64-bit integers). Twitter’s engineering team documented a production incident where 32-bit sequence numbers wrapped after 4.2 billion messages, causing duplicate detection to fail spectacularly.Performance implication: Maintaining ordered buffers for out-of-order packets adds memory overhead. Limit buffer size to prevent memory exhaustion attacks (max 1000 packets or 10MB per connection).Pattern 3: Adaptive Protocol SwitchingImplement runtime protocol switching based on observed network conditions:IF (packet_loss_rate > 5% over 60s window) THEN switch_to_TCP() backoff_time = min(backoff_time * 2, 300s) ELSE IF (packet_loss_rate Why this works: Network conditions are dynamic. A system shipping logs at 4 AM with 0.1% loss might face 8% loss during peak hours when shared infrastructure is saturated. Automatic switching prevents alerting fatigue while maintaining throughput.Failure mode to avoid: Rapid protocol oscillation (switching every few seconds) creates connection churn. Implement exponential backoff when switching back to UDP: 30s, 60s, 120s, capped at 5 minutes.Pattern 4: Batching and FramingUDP’s MTU (Maximum Transmission Unit) is typically 1500 bytes (minus IP/UDP headers = 1472 usable). Pack multiple log events into single UDP packets to amortize per-packet overhead:Framing strategy:[4 bytes: batch size][4 bytes: sequence number] [2 bytes: message 1 length][message 1 data] [2 bytes: message 2 length][message 2 data] ... Trade-off: Larger batches improve network efficiency but increase blast radius of packet loss. One lost 1400-byte packet containing 20 log events loses all 20 messages. Benchmark showed optimal batch size: 10-15 messages per packet for typical 80-byte log events.Pattern 5: Server-Side Load SheddingHigh-throughput UDP servers face a unique challenge: the kernel’s UDP receive buffer can overflow under load, silently dropping packets before your application reads them. Implement explicit load shedding:Linux tuning:# Increase UDP receive buffer to 25MB sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.rmem_default=26214400 Application-level shedding: Track processing queue depth. When queue exceeds threshold (e.g., 10,000 pending messages), send NACK to client, signaling them to slow down or switch protocols.Real-world example: Cloudflare’s logging infrastructure processes 10M requests/second. They discovered kernel buffer overflows were their primary packet loss source. Solution: Pre-allocate large buffers and implement backpressure signaling to upstream clients. Read more","published","strategy","content-ready","locked","deletedAt","isSyncedFromOwnBlog","original","duplicatesCount",0,"duplicateVersion","originalArticleId","errorsCount","appearance","color","backgroundColor","shortSummary","summary","bullets","persons","places","words","sentiment","subject","meta","eventId","68f6316f64ab7fd62e5016114ebf6ea99168169d478fa99d1bca32a65e19f0ba","nostrRootEvent","event",{"_25":170,"_198":223,"_200":224,"_103":225,"_203":31,"_139":226,"_205":227},"authorNPub","markdown","What We’re Building Today\n-------------------------\n\n* **UDP-based log shipper**handling 100K+ logs/second with configurable packet size\n \n* **Reliability layer**implementing application-level acknowledgments and sequence numbering\n \n* **Hybrid UDP/TCP fallback**system with automatic protocol switching under network degradation\n \n* **Production monitoring**tracking packet loss, throughput, and protocol efficiency metrics\n \n\n* * *\n\nWhy This Matters: The TCP Tax at Scale\n--------------------------------------\n\n> When Netflix ships millions of playback events per second or Uber processes location updates from millions of drivers, TCP’s reliability guarantees become a performance bottleneck. TCP’s three-way handshake, congestion control, and guaranteed delivery add 40-100ms latency per connection and consume significant server resources managing connection state.\n\n> UDP eliminates these overheads, offering 3-5x higher throughput for log shipping workloads where occasional packet loss is acceptable. The trade-off? You inherit responsibility for handling packet loss, ordering, and flow control at the application layer. Today’s implementation demonstrates how companies like Datadog and Splunk achieve massive log ingestion rates while maintaining acceptable reliability through selective UDP usage and intelligent fallback mechanisms.\n\n* * *\n\nSystem Design Deep Dive\n-----------------------\n\n[](https://substackcdn.com/image/fetch/$s_!5MPS!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe707dae9-d2a3-4456-af0e-b61a850643c5_830x616.png)\n\n### Pattern 1: Protocol Selection Strategy\n\nThe fundamental architectural decision is**when**to use UDP versus TCP. The industry pattern: UDP for high-volume telemetry (metrics, logs, traces) where individual message loss is tolerable, TCP for critical transactional data where guaranteed delivery is non-negotiable.\n\n**Trade-off Analysis:**\n\n* UDP provides 5-10x throughput improvement for small message sizes (<1400 bytes)\n \n* Acceptable packet loss threshold: 0.1-1% for metrics/logs, 0% for financial transactions\n \n* Network infrastructure consideration: Some enterprise firewalls block UDP, requiring TCP fallback\n \n\n**Anti-pattern:**Implementing custom reliability protocols over UDP. Don’t rebuild TCP. If you need guaranteed delivery with ordering, use TCP or a battle-tested protocol like QUIC.\n\n### Pattern 2: Application-Level Sequencing\n\nSince UDP doesn’t guarantee ordering, implement sequence numbers at the application layer. This enables:\n\n* **Gap detection**on the receiver to identify lost packets\n \n* **Out-of-order buffering**to reconstruct message sequences\n \n* **Duplicate detection**when network paths cause packet replication\n \n\n**Critical insight:**Sequence numbers must be monotonic and wrap-safe (use 64-bit integers). Twitter’s engineering team documented a production incident where 32-bit sequence numbers wrapped after 4.2 billion messages, causing duplicate detection to fail spectacularly.\n\n**Performance implication:**Maintaining ordered buffers for out-of-order packets adds memory overhead. Limit buffer size to prevent memory exhaustion attacks (max 1000 packets or 10MB per connection).\n\n### Pattern 3: Adaptive Protocol Switching\n\nImplement runtime protocol switching based on observed network conditions:\n\n IF (packet_loss_rate > 5% over 60s window) THEN switch_to_TCP() backoff_time = min(backoff_time * 2, 300s)ELSE IF (packet_loss_rate< 0.5% AND using_TCP) THEN try_UDP_after(backoff_time)\n\n**Why this works:**Network conditions are dynamic. A system shipping logs at 4 AM with 0.1% loss might face 8% loss during peak hours when shared infrastructure is saturated. Automatic switching prevents alerting fatigue while maintaining throughput.\n\n**Failure mode to avoid:**Rapid protocol oscillation (switching every few seconds) creates connection churn. Implement exponential backoff when switching back to UDP: 30s, 60s, 120s, capped at 5 minutes.\n\n### Pattern 4: Batching and Framing\n\nUDP’s MTU (Maximum Transmission Unit) is typically 1500 bytes (minus IP/UDP headers = 1472 usable). Pack multiple log events into single UDP packets to amortize per-packet overhead:\n\n**Framing strategy:**\n\n [4 bytes: batch size][4 bytes: sequence number][2 bytes: message 1 length][message 1 data][2 bytes: message 2 length][message 2 data]...\n\n**Trade-off:**Larger batches improve network efficiency but increase blast radius of packet loss. One lost 1400-byte packet containing 20 log events loses all 20 messages. Benchmark showed optimal batch size: 10-15 messages per packet for typical 80-byte log events.\n\n### Pattern 5: Server-Side Load Shedding\n\nHigh-throughput UDP servers face a unique challenge: the kernel’s UDP receive buffer can overflow under load, silently dropping packets before your application reads them. Implement explicit load shedding:\n\n**Linux tuning:**\n\n # Increase UDP receive buffer to 25MBsysctl -w net.core.rmem_max=26214400sysctl -w net.core.rmem_default=26214400\n\n**Application-level shedding:**Track processing queue depth. When queue exceeds threshold (e.g., 10,000 pending messages), send NACK to client, signaling them to slow down or switch protocols.\n\n**Real-world example:**Cloudflare’s logging infrastructure processes 10M requests/second. They discovered kernel buffer overflows were their primary packet loss source. Solution: Pre-allocate large buffers and implement backpressure signaling to upstream clients.\n\n[Read more](https://sdcourse.substack.com/p/day-10-udp-support-for-high-throughput)","freeMarkdown","kind1EventId","kind30023EventId","bf4b2d20654ff9a20330e4d998b0d0e3ee417bc911eb6e017c38f527b187893f","kind30023",{"_25":180,"_198":199,"_200":201,"_103":202,"_203":31,"_139":204,"_205":206},"publishedToNostr","htmlContentKind30023","

What We’re Building Today

\n
UDP-based log shipperhandling 100K+ logs/second with configurable packet size
\n
\n
Reliability layerimplementing application-level acknowledgments and sequence numbering
\n
\n
Hybrid UDP/TCP fallbacksystem with automatic protocol switching under network degradation
\n
\n
Production monitoringtracking packet loss, throughput, and protocol efficiency metrics
\n

Why This Matters: The TCP Tax at Scale

\n
When Netflix ships millions of playback events per second or Uber processes location updates from millions of drivers, TCP’s reliability guarantees become a performance bottleneck. TCP’s three-way handshake, congestion control, and guaranteed delivery add 40-100ms latency per connection and consume significant server resources managing connection state.
\n

\n
UDP eliminates these overheads, offering 3-5x higher throughput for log shipping workloads where occasional packet loss is acceptable. The trade-off? You inherit responsibility for handling packet loss, ordering, and flow control at the application layer. Today’s implementation demonstrates how companies like Datadog and Splunk achieve massive log ingestion rates while maintaining acceptable reliability through selective UDP usage and intelligent fallback mechanisms.
\n

System Design Deep Dive

Pattern 1: Protocol Selection Strategy

Trade-off Analysis:

\n
UDP provides 5-10x throughput improvement for small message sizes (<1400 bytes)
\n
\n
Acceptable packet loss threshold: 0.1-1% for metrics/logs, 0% for financial transactions
\n
\n
Network infrastructure consideration: Some enterprise firewalls block UDP, requiring TCP fallback
\n

**Anti-pattern:**Implementing custom reliability protocols over UDP. Don’t rebuild TCP. If you need guaranteed delivery with ordering, use TCP or a battle-tested protocol like QUIC.

Pattern 2: Application-Level Sequencing

Since UDP doesn’t guarantee ordering, implement sequence numbers at the application layer. This enables:

\n
Gap detectionon the receiver to identify lost packets
\n
\n
Out-of-order bufferingto reconstruct message sequences
\n
\n
Duplicate detectionwhen network paths cause packet replication
\n

**Critical insight:**Sequence numbers must be monotonic and wrap-safe (use 64-bit integers). Twitter’s engineering team documented a production incident where 32-bit sequence numbers wrapped after 4.2 billion messages, causing duplicate detection to fail spectacularly.

**Performance implication:**Maintaining ordered buffers for out-of-order packets adds memory overhead. Limit buffer size to prevent memory exhaustion attacks (max 1000 packets or 10MB per connection).

Pattern 3: Adaptive Protocol Switching

Implement runtime protocol switching based on observed network conditions:

IF (packet_loss_rate > 5% over 60s window) THEN switch_to_TCP() backoff_time = min(backoff_time * 2, 300s)ELSE IF (packet_loss_rate< 0.5% AND using_TCP) THEN try_UDP_after(backoff_time)\n

**Why this works:**Network conditions are dynamic. A system shipping logs at 4 AM with 0.1% loss might face 8% loss during peak hours when shared infrastructure is saturated. Automatic switching prevents alerting fatigue while maintaining throughput.

**Failure mode to avoid:**Rapid protocol oscillation (switching every few seconds) creates connection churn. Implement exponential backoff when switching back to UDP: 30s, 60s, 120s, capped at 5 minutes.

Pattern 4: Batching and Framing

UDP’s MTU (Maximum Transmission Unit) is typically 1500 bytes (minus IP/UDP headers = 1472 usable). Pack multiple log events into single UDP packets to amortize per-packet overhead:

Framing strategy:

[4 bytes: batch size][4 bytes: sequence number][2 bytes: message 1 length][message 1 data][2 bytes: message 2 length][message 2 data]...\n

**Trade-off:**Larger batches improve network efficiency but increase blast radius of packet loss. One lost 1400-byte packet containing 20 log events loses all 20 messages. Benchmark showed optimal batch size: 10-15 messages per packet for typical 80-byte log events.

Pattern 5: Server-Side Load Shedding

Linux tuning:

# Increase UDP receive buffer to 25MBsysctl -w net.core.rmem_max=26214400sysctl -w net.core.rmem_default=26214400\n

**Application-level shedding:**Track processing queue depth. When queue exceeds threshold (e.g., 10,000 pending messages), send NACK to client, signaling them to slow down or switch protocols.

**Real-world example:**Cloudflare’s logging infrastructure processes 10M requests/second. They discovered kernel buffer overflows were their primary packet loss source. Solution: Pre-allocate large buffers and implement backpressure signaling to upstream clients.

","pubDate",["D",1761988865000],"modifiedAt",["D",1761988865000],["D",1762426088805],"storyId","likes","zaps","comments","reposts","tweets",[],"sig","1e89f8aeb58698c03de8c8760d918cf6c387d7619ce15be32bcb467e0ffd0e3adaa9ea8d241766fad805013450d114836c3eb43b9237949e901cfe4c2f8a4312","kind",30023,[207,208,209,210,211,212,213,214],"pubkey","Day 10: UDP Support for High-Throughput Log Shipping\nWhat We’re Building Today\n-------------------------\n\n* **UDP-based log shipper**handling 100K+ logs/second with configurable packet size\n \n* **Reliability layer**implementing application-level acknowledgments and sequence numbering\n \n* **Hybrid UDP/TCP fallback**system with automatic protocol switching under network degradation\n \n* **Production monitoring**tracking packet loss, throughput, and protocol efficiency metrics\n \n\n* * *\n\nWhy This Matters: The TCP Tax at Scale\n--------------------------------------\n\n> When Netflix ships millions of playback events per second or Uber processes location updates from millions of drivers, TCP’s reliability guarantees become a performance bottleneck. TCP’s three-way handshake, congestion control, and guaranteed delivery add 40-100ms latency per connection and consume significant server resources managing connection state.\n\n> UDP eliminates these overheads, offering 3-5x higher throughput for log shipping workloads where occasional packet loss is acceptable. The trade-off? You inherit responsibility for handling packet loss, ordering, and flow control at the application layer. Today’s implementation demonstrates how companies like Datadog and Splunk achieve massive log ingestion rates while maintaining acceptable reliability through selective UDP usage and intelligent fallback mechanisms.\n\n* * *\n\nSystem Design Deep Dive\n-----------------------\n\n[](https://substackcdn.com/image/fetch/$s_!5MPS!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe707dae9-d2a3-4456-af0e-b61a850643c5_830x616.png)\n\n### Pattern 1: Protocol Selection Strategy\n\nThe fundamental architectural decision is**when**to use UDP versus TCP. The industry pattern: UDP for high-volume telemetry (metrics, logs, traces) where individual message loss is tolerable, TCP for critical transactional data where guaranteed delivery is non-negotiable.\n\n**Trade-off Analysis:**\n\n* UDP provides 5-10x throughput improvement for small message sizes (<1400 bytes)\n \n* Acceptable packet loss threshold: 0.1-1% for metrics/logs, 0% for financial transactions\n \n* Network infrastructure consideration: Some enterprise firewalls block UDP, requiring TCP fallback\n \n\n**Anti-pattern:**Implementing custom reliability protocols over UDP. Don’t rebuild TCP. If you need guaranteed delivery with ordering, use TCP or a battle-tested protocol like QUIC.\n\n### Pattern 2: Application-Level Sequencing\n\nSince UDP doesn’t guarantee ordering, implement sequence numbers at the application layer. This enables:\n\n* **Gap detection**on the receiver to identify lost packets\n \n* **Out-of-order buffering**to reconstruct message sequences\n \n* **Duplicate detection**when network paths cause packet replication\n \n\n**Critical insight:**Sequence numbers must be monotonic and wrap-safe (use 64-bit integers). Twitter’s engineering team documented a production incident where 32-bit sequence numbers wrapped after 4.2 billion messages, causing duplicate detection to fail spectacularly.\n\n**Performance implication:**Maintaining ordered buffers for out-of-order packets adds memory overhead. Limit buffer size to prevent memory exhaustion attacks (max 1000 packets or 10MB per connection).\n\n### Pattern 3: Adaptive Protocol Switching\n\nImplement runtime protocol switching based on observed network conditions:\n\n IF (packet_loss_rate > 5% over 60s window) THEN switch_to_TCP() backoff_time = min(backoff_time * 2, 300s)ELSE IF (packet_loss_rate< 0.5% AND using_TCP) THEN try_UDP_after(backoff_time)\n\n**Why this works:**Network conditions are dynamic. A system shipping logs at 4 AM with 0.1% loss might face 8% loss during peak hours when shared infrastructure is saturated. Automatic switching prevents alerting fatigue while maintaining throughput.\n\n**Failure mode to avoid:**Rapid protocol oscillation (switching every few seconds) creates connection churn. Implement exponential backoff when switching back to UDP: 30s, 60s, 120s, capped at 5 minutes.\n\n### Pattern 4: Batching and Framing\n\nUDP’s MTU (Maximum Transmission Unit) is typically 1500 bytes (minus IP/UDP headers = 1472 usable). Pack multiple log events into single UDP packets to amortize per-packet overhead:\n\n**Framing strategy:**\n\n [4 bytes: batch size][4 bytes: sequence number][2 bytes: message 1 length][message 1 data][2 bytes: message 2 length][message 2 data]...\n\n**Trade-off:**Larger batches improve network efficiency but increase blast radius of packet loss. One lost 1400-byte packet containing 20 log events loses all 20 messages. Benchmark showed optimal batch size: 10-15 messages per packet for typical 80-byte log events.\n\n### Pattern 5: Server-Side Load Shedding\n\nHigh-throughput UDP servers face a unique challenge: the kernel’s UDP receive buffer can overflow under load, silently dropping packets before your application reads them. Implement explicit load shedding:\n\n**Linux tuning:**\n\n # Increase UDP receive buffer to 25MBsysctl -w net.core.rmem_max=26214400sysctl -w net.core.rmem_default=26214400\n\n**Application-level shedding:**Track processing queue depth. When queue exceeds threshold (e.g., 10,000 pending messages), send NACK to client, signaling them to slow down or switch protocols.\n\n**Real-world example:**Cloudflare’s logging infrastructure processes 10M requests/second. They discovered kernel buffer overflows were their primary packet loss source. Solution: Pre-allocate large buffers and implement backpressure signaling to upstream clients.\n\n[Read more](https://sdcourse.substack.com/p/day-10-udp-support-for-high-throughput)\nYou can include dynamic values by using placeholders like: https://drewdru.syndichain.com/articles/9269027d-0197-4400-a2c6-ee4f2fcb4861 , Drew Dru, https://sdcourse.substack.com/p/day-10-udp-support-for-high-throughput , npub1897arz, npub1897arz, npub1897arz, \n\nnpub1897arz These will automatically be replaced with the actual data when the message is sent. https://drewdru.syndichain.com/articles/9269027d-0197-4400-a2c6-ee4f2fcb4861 npub1897arz\n","created_at",1761988865,[221,222],[36,125],[219,220],[39,131],[218,119],[161,126],[216,217],[215,31,41],"p","client","Layer3.press","d","published_at","1761988865","r","https://drewdru.syndichain.com/articles/9269027d-0197-4400-a2c6-ee4f2fcb4861","f129a66932be22306ccbe073975ef21a364c5ef3643fe8eb0e29b5b4cc5b421de0518b16b33216314b361a1a832bf2c731bbd50848b2a8cbf658f886128be119",1,[228,229,230,231,232],"Day 10: UDP Support for High-Throughput Log Shipping\nWhat We’re Building Today\n\n\nnostr:naddr1qvzqqqr4gupzp5fxzjl8yczfclk0ades0f3a8pqchwptjxrxhpmy4ypl728dnx7xqqjrjv3k8ycrydmy95crzwfh956rgvps94snycek94jk2drxxfnxxc358qmrzu64wlh ",1766562286,[167,125],[39,131],[233,234,41,235],[216,217],[215,31,41],"a","30023:d12614be726049c7ecfeb7307a63d38418bb82b91866b8764a903ff28ed99bc6:9269027d-0197-4400-a2c6-ee4f2fcb4861","mention","userSubscription","theme","light","currentUser","currentUserVersion2","currentPath","/articles/9269027d-0197-4400-a2c6-ee4f2fcb4861","customDomain","defaultLocale",[],"domainPrimaryAccentColor","relays",[289,290,291,292,289],"plans",[267,268],[77,78],"isDomainOwner","userInterfaceLanguage","interfacePreferences","session",{"_100":-5,"_263":12,"_264":265,"_72":245},"locale","sessionNpub","sessionPublicKey","hostname","drewdru.syndichain.com","syndicated","isAdmin","rights",{"_266":12},"owner",{"_25":283,"_270":284,"_38":285,"_273":286,"_275":276,"_277":278,"_279":153,"_280":23,"_47":287,"_49":288},{"_25":269,"_270":271,"_38":272,"_273":274,"_275":276,"_277":278,"_279":153,"_280":23,"_47":281,"_49":282},"3982e6ff-f607-4102-a24c-36c9fd4baf5e","name","Test Plan on Syndichain","TEST Plan description","price","6.00","currency","USD","billingInterval","monthly","trialDays","isActive",["D",1756209805178],["D",1756209805178],"1fd9543f-3ba9-4c83-914a-a4376d4dd8d6","Free plan","Free notifications about new articles","0.00",["D",1758187216959],["D",1758187216959],"wss://articles.layer3.news","wss://nostr-01.yakihonne.com","wss://relay.primal.net/","wss://relay.primal.net"]