LLMs are breaking 20 year old system design

기존 20년 된 클라우드 네이티브 아키텍처는 데이터베이스에 상태를 두고 컴퓨트는 무상태라는 가정에 기반한다. 하지만 LLM과 에이전트는 장시간 실행, 상태 유지, 양방향 상호작용을 요구하며 이 가정을 깨고 있다. 현재 Durable Execution(Temporal 등)이 실행 내구성을 제공하지만, HTTP와 로드밸런서 기반의 무상태 서버는 특정 프로세스에 라우팅할 수 없어 폴링에 의존하는 한계가 있다. 해결책으로는 pub/sub 채널을 통한 내구성 있는 라우팅 프리미티브가 필요하며, 이는 LLM의 비결정적이고 비용이 큰 특성 때문에 더욱 중요해졌다.

https://zknill.io/posts/llms-are-breaking-20-year-old-system-design/

#llm #systemdesign #durableexecution #pubsub #routing

LLMs are breaking 20 year old system design — /dev/knill

Web architecture is built on a 20-year-old assumption that state lives in the database, and compute is stateless. But we're missing a routing primitive.

/dev/knill
NATS Pub/Sub in Hare - Blain Smith

I got hare-nats wired to use hare-ev now so I can start to really get this more feature complete. It does the very basic connection, publish, and subscribe work. It still needs more love around memory allocations and additional NATS protocol support for credentials, etc.

#HareLang #NATS #PubSub

Durable queues, streams, pub/sub, and a cron scheduler – inside your SQLite file

https://honker.dev/

#HackerNews #DurableQueues #SQLite #Streams #PubSub #CronScheduler

Honker

Durable queues, streams, pub/sub, and scheduler on SQLite. One file, zero servers.

Honker

Github Awesome (@GithubAwesome)

SQLite용 로드 가능한 Rust 확장인 Honker가 공개됐다. Postgres의 NOTIFY/LISTEN을 SQLite에 네이티브로 제공해, 기존 단일 파일 DB만으로도 durable pub/sub, 작업 큐, 이벤트 스트림을 구현할 수 있게 한다.

https://x.com/GithubAwesome/status/2047876989009207414

#sqlite #rust #database #pubsub #opensource

Github Awesome (@GithubAwesome) on X

SQLite's single-file magic breaks the moment you need a task queue. Honker is a loadable SQLite extension written in Rust that brings Postgres-style NOTIFY and LISTEN natively to SQLite. Durable pub/sub, task queues, event streams, all in your existing database file. Same atomic

X (formerly Twitter)

New progress note available (after 3 years during which I posted here on ActivityPub instead of on the blog):

https://www.goffi.org/id/libervia-progress-note-2026-w16-ooph

I'm talking about current work on installation/configuration simplification and the new forge, focus on web frontend and redesign and work done with current metadata reduction and serverless XMPP (Tor, contacts e2ee, new pubsub implementation).

#Libervia #progress #XMPP #NLnet #NCI0 #Tor #pubsub #decentralized #forge #metadata #serverless

I've just pushed a new pubsub implementation (basically a reimplementation of SàT/Libervia Pubsub on top of Libervia Backend).

May not sound exciting like that, but it's a major thing for many reasons, I hope that I can find time to blog about that tomorrow.

Also it implements XEP-0496 (Pubsub Node Relationships) and XEP-0499 (Pubsub Extended Discovery) which means node hierarchy, useful for things like forums.

This is context of https://nlnet.nl/project/ServerlessXMPP/

#Libervia #XMPP #Pubsub #nlnet #ngi0

NLnet; Serverless and Metadata Reduction for XMPP

Kafka: Queue & Pub-Sub Together 📨

Queue (1-to-1):
1 consumer group, consumers = partitions
Each message → 1 consumer only

Pub-Sub (1-to-many):
Multiple consumer groups
Each group → all messages

Traditional systems need separate tools.
Kafka does both natively!

#Kafka #MessageQueue #PubSub #DevOps

Server-Sent Events Beat WebSockets for 95% of Real-Time Apps (Here's Why) - DEV Community

"Everyone defaults to WebSockets for real-time features. Most shouldn't.

The reality: 95% of "real-time" applications only need server → client updates. Chat notifications. Live dashboards. Stock tickers. Log streams. AI responses.

WebSockets give you bidirectional communication. But bidirectional comes with a tax: complexity, resource overhead, scaling challenges, debugging nightmares.

Server-Sent Events (SSE) do one thing: stream data from server to client. They do it brilliantly. And for..."

https://dev.to/polliog/server-sent-events-beat-websockets-for-95-of-real-time-apps-heres-why-a4l?context=digest

#events #http #pubsub #sse #webdev
Broadcast Channel API - Web APIs | MDN

"The Broadcast Channel API allows basic communication between browsing contexts (that is, windows, tabs, frames, or iframes) and workers on the same origin.

By creating a BroadcastChannel object, you can receive any messages that are posted to it. You don't have to maintain a reference to the frames or workers you wish to communicate with: they can "subscribe" to a particular channel by constructing their own BroadcastChannel with the same name, and have bi-directional communication between a..."

https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API

#pubsub #webdev
Broadcast Channel API - Web APIs | MDN

The Broadcast Channel API allows basic communication between browsing contexts (that is, windows, tabs, frames, or iframes) and workers on the same origin.

MDN Web Docs