latency-shaped real-world feedback

[antonpiat]

Hi, I looked through the crate and Benchmark results in github repo, really impressive work.

I'm not an expert on lock-free queue design but I'm interested!
Your sharded channels and unified sync/async API caught my attention, especially shard_key for per-market ordering and bounded backpressure.

I’m building a Solana trade bot, which is an arbitrage multi venue engine using linux bare metal servers, so I can test in reporting latency under burst.
I run my own RPC (non-validator) and ingest shreds directly, so market data is very bursty.
I think HEL could fit well on the ingest side: many feeds pushing updates at once, and routing by venue or pool id with shard_key seems like a natural match for per-market ordering without bridges between sync and async.

I'd love to dogfood HEL there and report back, I mean latency under burst, try_send vs blocking, shard/cap tuning on real hardware.
Happy to open an issue to track it or start with a minimal ingest example if that's useful.

Thanks for open sourcing.

[vladbpython]

Hi, I looked through the crate and Benchmark results in github repo, really impressive work.

I'm not an expert on lock-free queue design but I'm interested! Your sharded channels and unified sync/async API caught my attention, especially shard_key for per-market ordering and bounded backpressure.

I’m building a Solana trade bot, which is an arbitrage multi venue engine using linux bare metal servers, so I can test in reporting latency under burst. I run my own RPC (non-validator) and ingest shreds directly, so market data is very bursty. I think HEL could fit well on the ingest side: many feeds pushing updates at once, and routing by venue or pool id with shard_key seems like a natural match for per-market ordering without bridges between sync and async.

I'd love to dogfood HEL there and report back, I mean latency under burst, try_send vs blocking, shard/cap tuning on real hardware. Happy to open an issue to track it or start with a minimal ingest example if that's useful.

Thanks for open sourcing.

Thanks a lot.
I'd be really interested in your results.

One important clarification on shard_key, since it affects how you'd wire the
ingest side:
shard_key guarantees per key ordering, but NOT a dedicated shard per key.
It routes by hash(key) & mask, so:

• the same key (pool id / venue) always lands on the same shard → per market
  ordering is preserved
• but different keys can collide onto the same shard (hash collision) - it does
  not isolate markets onto separate shards.
  So shard_key is really about even load distribution + per key ordering,
  not "this market goes to exactly that shard".

If you want explicit isolation (e.g. "this set of pools → shard 0, that set
→ shard 1"), that's shard_group - you give it an explicit map (by venue, pool
group, or liquidity tier) and it routes deterministically by that map, returning
unregistered keys as orphans instead of misrouting them. The trade off:
shard_group needs the keys known up front; shard_key handles arbitrary/
dynamic keys but with possible collisions.

For Solana ingest, a common pattern:

• shard_key if you have many dynamic pool ids and just want them spread
  evenly with per pool ordering (collisions are fine - a shard handles several
  pools, each still ordered).
• shard_group if you want to pin hot venues/pools to their own shards
  (isolation, no noisy neighbor effect from a busy market).

[antonpiat]

Make sense! Thanks for the clarification.
shard_key keeps per-pool ordering but doesn't give each pool its own shard, collisions are expected.
per-key ordering, not per-key isolation
I have more than 3000 filtered pools across 30+ venues(filtered from millions of pools).

This is my current bot logic.

1. Shred arrives
2. Figure out which pool(s) changed
3. For that pool → look up saved routes (2–4 hop paths in my poolpath DB)
4. Check if any path is profitable now
5. If yes → build and send tx

So, shred parse → pool update → shard_key by pool id → worker threads
I'll start with shard_key by pool id since there are 3000 pools.

[vladbpython]

Make sense! Thanks for the clarification. shard_key keeps per-pool ordering but doesn't give each pool its own shard, collisions are expected. per-key ordering, not per-key isolation I have more than 3000 filtered pools across 30+ venues(filtered from millions of pools).

This is my current bot logic.

1. Shred arrives

2. Figure out which pool(s) changed

3. For that pool → look up saved routes (2–4 hop paths in my poolpath DB)

4. Check if any path is profitable now

5. If yes → build and send tx

So, shred parse → pool update → shard_key by pool id → worker threads I'll start with shard_key by pool id since there are 3000 pools.

Yep, shard_key by pool id is the right call for 3000 dynamic pools - automatic
even distribution + per pool ordering, no manual map to maintain as your filtered
set changes. Your pipeline maps cleanly onto it: shred → pool update →
shard_key(pool_id) → worker, with each pool's updates staying ordered on one
shard (which matters since you're reacting to sequential state changes per pool).

The one thing to watch: a few pools will be far hotter than the rest.
With pure shard_key, a hot pool shares a shard with 100+ others by hash, so when it bursts, its worker is busy and updates for the
other pools on that shard queue up behind it - noisy neighbor tail latency.

If you see that in your p99/p999, a nice choice is a hybrid:

• pin the handful of hottest pools to their own dedicated shards via shard_group
  (explicit isolation - they get a worker each, no neighbors)
• route everything else through shard_key as planned (the long tail of 3000,
  even distribution)

[vladbpython]

Make sense! Thanks for the clarification. shard_key keeps per-pool ordering but doesn't give each pool its own shard, collisions are expected. per-key ordering, not per-key isolation I have more than 3000 filtered pools across 30+ venues(filtered from millions of pools).
This is my current bot logic.

1. Shred arrives

2. Figure out which pool(s) changed

3. For that pool → look up saved routes (2–4 hop paths in my poolpath DB)

4. Check if any path is profitable now

5. If yes → build and send tx

So, shred parse → pool update → shard_key by pool id → worker threads I'll start with shard_key by pool id since there are 3000 pools.

Yep, shard_key by pool id is the right call for 3000 dynamic pools - automatic even distribution + per pool ordering, no manual map to maintain as your filtered set changes. Your pipeline maps cleanly onto it: shred → pool update → shard_key(pool_id) → worker, with each pool's updates staying ordered on one shard (which matters since you're reacting to sequential state changes per pool).

The one thing to watch: a few pools will be far hotter than the rest. With pure shard_key, a hot pool shares a shard with 100+ others by hash, so when it bursts, its worker is busy and updates for the other pools on that shard queue up behind it - noisy neighbor tail latency.

If you see that in your p99/p999, a nice choice is a hybrid:

* pin the handful of hottest pools to their own dedicated shards via `shard_group`
  (explicit isolation - they get a worker each, no neighbors)

* route everything else through `shard_key` as planned (the long tail of 3000,
  even distribution)

I'd start with pure shard_key, measure, and only add the hybrid if
the tail actually shows the noisy neighbor effect, no point complicating it
before the data says so.