Felix
Status

Where Felix is today

Felix is young. This is what works today, what's next, and where it fits.

Status by area, one mark per row of the status table. Delivery: 8 today, 1 partial; Clustering: 10 today, 4 partial, 1 planned; Durable streams and state: 8 today, 3 partial; Access and operations: 8 today, 5 partial.DeliveryClusteringDurable streams and stateAccess and operations
Status table

What works today, and what's next

Felix is pre-1.0, so the API can change between releases. The marks follow the status table in the docs, row for row.

Today implemented and tested Partial real, but incomplete Planned not built yet

Delivery

  • TodayPublish and subscribe with high fanout
  • TodayBatched publish and delivery
  • TodayBounded per-subscriber queues
  • TodaySlow-consumer isolation
  • TodayIdempotent producers
  • TodayConditional publish and commit
  • TodayPublisher identity on delivered events
  • TodayGap-free current state, then changes
  • PartialGraceful shutdownWriters inside a connection aren't told to wind down early

Clustering

  • TodaySharding
  • TodayQuorum acknowledgement
  • TodayLinearizable Quorum reads
  • TodayLeader failover
  • TodayPipelined publishes
  • TodayOnline rebalancing
  • TodayReplication factor restore
  • TodayZone-aware placement
  • TodayClients that survive a broker failure
  • TodayFleet-wide feature gate
  • PartialMulti-node clusteringThe control plane decides every failover
  • PartialConsistent backup pointOffsets are read one broker at a time, with no write pause
  • PartialRaft for cluster metadata
  • PartialCross-region routingBrokers don't check regions themselves
  • PlannedLoad-aware placement

Durable streams and state

  • TodayDurable streams
  • TodayResumable subscriptions
  • TodayBounded range reads
  • TodayRecord times and replay from a time
  • TodayKey/value cache with TTL
  • TodayCompare-and-set cache writes
  • TodayKeyed cache watch
  • TodayCounters
  • PartialConsumer groupsA group is bound to one shard
  • PartialLog-backed cacheThe key index is held whole in memory
  • PartialAtomic event and state commitsA re-sent commit may land twice

Access and operations

  • TodayQUIC, with TLS 1.3 always on
  • TodayTenants and namespaces
  • TodayToken-based authorization and revocation
  • TodayKafka consumers
  • TodayKafka Produce
  • TodayControl-plane metadata service
  • TodayPrometheus metrics and health endpoints
  • TodayKubernetes packaging
  • PartialPer-tenant quotasNo quotas on subscriptions, cache or storage yet
  • PartialTiered storageOffload only, nothing reads it back yet
  • PartialClients beyond RustPython and TypeScript ship; Go and C# are not started
  • PartialfelixctlState reads are not built yet
  • PartialOperator inspectionNo connection listing or offline record decoding yet

What's next

  1. 0.6 now

    Moving shards between brokers without downtime, with each stream's leaders spread across them, and numbers for replicated streams on a three-broker cluster. Durable streams acknowledge a publish once it is written, and a new cluster turns on the fleet features its brokers support, publisher identity aside, without an operator step. Subscriber queues are held to a byte budget; QUIC receive windows and the cache key index are next.

  2. 0.7 next

    Open in the 0.7 milestone: failover that doesn't wait on the control plane's lease, subscriptions that stop at an end offset, per-key checks on commits, reads from tiered storage, and Go and C# clients.

  3. 1.0 later

    A stability promise, backed by a long-running public workload on Felix.

The full status tableMilestones on GitHub

Fit

When to use Felix, and when not to

Felix is young. This is where it fits today, and where it doesn't yet.

Good fit

  • Live collaboration and fanout to many clients. A publish is encoded once however many subscribers it reaches, and a slow subscriber falls behind on its own. Browsers connect through felix-gateway.
  • Streams with state beside them. Caches with keyed watches, counters and consumer groups sit on the same log as the stream, behind one client and one set of grants.
  • Multi-tenant products. Every operation is scoped to a tenant and namespace, and tokens are narrowed to the actions and resources a tenant was granted.
  • Per-stream choices. Each stream picks in memory or durable, and Leader or Quorum acknowledgement, so one cluster can carry both throwaway and must-keep data.

Not yet

  • You need the Kafka ecosystem. Felix serves Kafka producers and consumers that assign their own partitions, but has no consumer groups or transactions over the Kafka protocol, so Kafka Connect, Kafka Streams and ksqlDB don't run.
  • You need proven scale. Published numbers come from one broker and from a three-broker cluster. Larger clusters and a long-running public workload are still to come.
  • You need Go or C#. Clients ship for Rust, Python and TypeScript. Go and C# are not started.
  • You need a 1.0 stability promise. Felix is pre-1.0, and its API, wire protocol and semantics can change between releases.

Workload by workload