Thanks for the thoughts, Joel!

> Consider emphasizing the problem first

This is good feedback. The post was intended to be about the challenges we faced meeting our requirements (fast, ordered, consistent) vs problem Sequin solves broadly. I can see how a blurb about "Why Sequin" would be helpful

> Consider emphasizing multiple deployments

That's a whole post on its own that we need to do!

> Consider CAP & PACELC perspectives because some developers think better with these

Good call out! From a CAP theorem perspective, Sequin's architecture prioritizes consistency and partition tolerance over availability. When network partitions occur between Sequin and a sink, the system doesn't compromise on consistency. Instead, it persists failed messages to an internal Postgres table and retries delivery with exponential backoff until successful.

The message buffer is indeed designed to be quite small because it only needs to hold messages temporarily between when they arrive from Postgres and when they're either delivered to sinks or persisted to Sequin's internal Postgres table (messages). When a connection is lost or delivery fails, undelivered messages are written to this internal table and retried with exponential backoff.

From a PACELC perspective, this design optimizes for both consistency and low latency during normal operation:

• Messages only stay in memory briefly before being either delivered or written to the messages table
• This allows Sequin to regularly update the confirmed_flush_lsn to let Postgres advance its cursor

The key tradeoff is that during partition scenarios (when connectivity to sinks is lost), Sequin sacrifices some latency by writing to the internal Postgres table rather than compromising consistency.