<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>realtime on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/tags/realtime/</link><description>Recent content in realtime on Ikoma's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 19 Sep 2026 21:10:16 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/tags/realtime/index.xml" rel="self" type="application/rss+xml"/><item><title>APNs Stores One Pending Notification per App, So Treat Push as a Hint</title><link>https://blog.yusukeikoma.com/posts/push-notifications-are-hints-apns-stores-one/</link><pubDate>Sat, 19 Sep 2026 21:10:16 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/push-notifications-are-hints-apns-stores-one/</guid><description>Apple and Google both document what happens to a push when the device is offline, the app is killed or the sender is too chatty: messages are replaced, dropped, reordered or delayed. A table of those documented failure modes, and a small simulation showing that a client which pulls from a cursor converges where a client which applies push payloads does not.</description></item><item><title>Waiting for bufferedAmount Protects the Sender, Not a Slow Consumer</title><link>https://blog.yusukeikoma.com/posts/websocket-bufferedamount-backpressure/</link><pubDate>Sun, 06 Sep 2026 20:54:24 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/websocket-bufferedamount-backpressure/</guid><description>WebSocket send() never waits, and bufferedAmount only sees the part of the path that is in your own process. In a small lab, a sender that politely waited for bufferedAmount to drain still let a slow consumer queue nearly all 400 messages in its own memory, while a credit window of 8 kept the backlog at 8. This post goes through four common beliefs about send(), bufferedAmount, message size and backpressure, tests each one, and ends with a table for choosing between them.</description></item><item><title>Resuming an Event Stream with a Cursor, a Bounded Log and a Snapshot</title><link>https://blog.yusukeikoma.com/posts/resumable-streams-cursors-last-event-id-snapshots/</link><pubDate>Fri, 04 Sep 2026 19:26:37 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/resumable-streams-cursors-last-event-id-snapshots/</guid><description>How a client catches up after a reconnect without losing state, without duplicates, and without re-reading history. Built in steps (versions 0 to 4), from &amp;ldquo;read everything again&amp;rdquo; to a bounded log with a snapshot fallback, with what a real browser&amp;rsquo;s EventSource does on reconnect and on a non-200 response, a snapshot-ordering bug, and a decision tree.</description></item><item><title>Edge-Triggered epoll Hangs After a Partial Read, and Event Streams Break the Same Way</title><link>https://blog.yusukeikoma.com/posts/level-triggered-invalidation/</link><pubDate>Tue, 25 Aug 2026 17:33:01 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/level-triggered-invalidation/</guid><description>epoll&amp;rsquo;s edge-triggered mode stalls after a partial read; level-triggered mode cannot. The same distinction decides whether a realtime client survives lost, duplicated and reordered events. A reproducible epoll experiment, a five-way simulation on a lossy channel, and a 40-line invalidator that handles the race everyone misses: an event that arrives while the refetch is running.</description></item><item><title>Replace Polling with Change Subscriptions, and Keep the Poll as the Fallback</title><link>https://blog.yusukeikoma.com/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/</link><pubDate>Thu, 20 Aug 2026 18:03:49 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/</guid><description>How a mobile client moved from timer-driven polling to shared change subscriptions over a per-message-billed relay. The subtle part is not the stream. It is deciding honestly when the fallback poll may stand down.</description></item><item><title>Separate the Live Document from the Saved Copy</title><link>https://blog.yusukeikoma.com/posts/live-document-and-saved-copy/</link><pubDate>Thu, 13 Aug 2026 10:14:09 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/live-document-and-saved-copy/</guid><description>Designing collaborative document editing with conflict-free synchronization, saved snapshots, and safeguards against overwriting content before initial sync.</description></item></channel></rss>