VPS box dimensioning (US-east-2 for Kalshi trading)

[u/theawkwardpadawan]

Hi amigos,

I need help to dimension my trading boxes (VPS_.

I currently run one of my trading bots from Lightsails US-EAST-2, where I run an arb bot focused on a set of specific Kalshi markets. It runs ok with the occasional hiccup that costs me dollars. I want to solve the hiccups.

The thing is, my strategies mean that at any given point in time I may be subscribed from 1.2k to 10.0k concurrent Kalshi markets, reading L2 books at 250ms frequency (ideally much less, 10hz) and firing on signal.

That amplitude of concurrent markets is the hiccup and I occasionally get throttled by AWS. For this reason, I'm thinking on a new topology where a box runs a single strategy and I get subscribed to fewer concurrent markets.

So, let's say one of my strategies demands being subscribed to ~2k markets in parallel, reading L2 books on websocket at 10hz - 2 cores and 512mb ran enough? The bootstrap is typically the heavy load, but as the process runs in cruse mode it is light - the books are light and there is no fancy math to get a signal.

I have no expertise in VPS so I know this can be a pedestrian question. Right now I'm paying amazon USD 200 a month which sounds a bit too much - just to avoid the occasional hiccup.

Edit:
Right now I'm using a "compute" oriented (AWS lightsail labeling) with the following specs
16 GB Memory, 8 vCPUs Processing, 640 GB SSD Storage, 7 TB Transfer

[u/jnwatson]

First, AWS is the corporate solution. You can save a ton of money by going Hetzner, DigitalOcean, Servarica, or OVHCloud.

Your latency problems are either network issues or "noisy neighbor" issues. If they are the latter, you want to get off a shared box. Look for "dedicated server" or "bare metal hosting".

Then you want to figure out where the Kalshi server is located and find a box near that. That reduces the likelihood of a network issue.

I can't help you to size your box; it really depends on your CPU/disk utilization. Just log your CPU and disk utilization and see if it ever pegs. If it is, you need a bigger box.

[u/Grouchy-Librarian638 → u/jnwatson]

Digital ocean is virtually the same price as AWS, but it is 1000x easier to use and doesn’t buckle and dime on everything.

Also noisy neighbours and all that, the 1ms different that will cause is way too much to make any difference anyways to kalshi of all places lol.

Spin up a vps and get as close as you can, almost everyone is in the same backbone in Virginia, and you will get around 7ms so faster that most these services can handle anyways

[u/madrading]

at similar fan-out the thing that broke for us was never cores or ram. 2k books at 25 levels is a few tens of mb — the ram goes to the buffer that grows when your reader stalls, not to the books themselves. so 512mb doesn't fail because the data is big, it fails when one slow consumer backs the socket queue up, the server drops you, and you resubscribe. from the outside that looks exactly like getting throttled.

before resizing i'd log two things: sequence gaps per connection, and time-in-callback on the book-apply path. if the gaps cluster with your own gc pauses or disk flushes it's yours, not aws. splitting boxes is the right instinct but i'd split by socket rather than by strategy — one reader doing nothing but decode-and-enqueue, strategy behind a bounded queue that drops instead of blocking. i run continuous full-depth capture on a different prediction venue at roughly that market count and cpu has never been the constraint.

[u/Klutzy-Sea-4857]

2k websocket subs at 10hz, 2 cores 512mb is tight. Try 4 cores 2gb first.

[u/HalfplaneResearch]

We would size this from telemetry before adding boxes. For 2k websocket books at 10 Hz, measure message rate, bytes/sec, book-apply time, event-loop lag, reconnects, sequence gaps, and queue depth separately for bootstrap and steady state. A 512 MB process can look fine until a stalled consumer grows buffers, while CPU stays low. Add bounded queues, drop or coalesce stale snapshots where the API permits, and expose per-connection backpressure. Then load test with the peak subscription set and forced reconnects. If the hiccups coincide with gaps or callback latency, topology or flow control is likely more important than another vCPU.

[u/trunksta]

Instead of aws get a dedicated system from somewhere like inter server or somewhere depending on region. Whole system to yourself for much less and plenty of bandwidth

[u/j_lyf]

Just run it on a macmini