Infrastructure and Co-location
We are literally paranoid about how we run trading infrastructure. That is why it works.
When your trading, your regulatory reporting, or your research depends on co-located servers, the infrastructure behind it is either a problem you manage or a problem someone already solved. algoseek has spent two decades making sure it’s the latter.
Our infrastructure at a glance
2
decades building trading infrastructure
5
Equinix facilities: NY2, NY4, NY5, CH1, CH2
0
SLA failures, even under market volatility
4-way
arbitration across redundant feeds
30TB
OPRA data processed per day
2
regions: fully redundant across NJ and Chicago
Trusted by
Two US regulators
Custom OPRA NBBO calculations in production
Bulge bracket banks
Index TWAPs and intraday QIS calculations
Hedge funds
Raw multicast delivered into AWS across regions
Prop trading firms
Custom-built servers and private network delivery
How We Build
Things break. The question is whether you built for it.
algoseek’s founding team has been building trading infrastructure for nearly two decades. Not buying Dell servers and replacing them when they fail, but digging into every problem encountered, from data congestion to CPU meltdowns, figuring out how to prevent it from happening at all.
Custom servers, not off-the-shelf
Manufacturers skimp wherever they can. Fans fastened with cheap plastic pins that vibrate loose within a year. Aluminum heat sinks that can’t handle sustained trading workloads. algoseek glues fans down, uses custom copper coolers manufactured to specification, matches motherboards and memory cards by production year and location, and uses network cards with dedicated processing chips for data-capture servers.
“
We glue the damn fan, so it stays where it belongs. And not just the fan. We glue cables so they never wander into a fan’s spinning blades.
Testing: twice before it touches a rack
Every component tested individually. Assembled servers tested at the office: OS sees all disks, memory tests, every cable verified. Then the server travels to the data center and the entire suite runs again before anything goes into a cabinet. If a server that passed in the office fails even one test at the data center, the entire unit goes back. No troubleshooting in noisy, cold rooms that breed sloppy work.
“
Experience changes a person, and apparently a server too. Bad things happen during the journey: memory comes off socket, hard drives wiggle loose, cables lose their snug fit.
Preventive monitoring, not failure detection
Commercial monitoring tools watch for failure. By the time they alert, the damage is done. algoseek built its own monitoring tools from scratch, digging into low-level OS logs for early indicators most tools wave off as non-critical: an SSD going from 5 bad sectors to 20 in a week, a network switch issuing pause frames before any packets drop, a fan temperature drifting outside expected variance. Catch problems when they are whispers, not alarms.
“
When you monitor for failure, you already failed.
Changes only on Saturdays
No changes during the production week. Even if something fails, the fix goes in on Saturday, because touching one server can dislodge a cable on the next one. Every data center visit is scripted a week in advance, printed on paper, and logged down to which cable connects which port. Spare parts stocked excessively. If a server goes down mid-week, a pre-tested spare goes in. The failed unit comes back to the office for diagnosis.
“
Fail to plan, end up crawling through a jungle of cables while slowly losing your soul.
Data integrity as the goal
Listener servers sit on each data link, capturing every packet to verify no drops occur. Missing sequence numbers mean dropped packets. Exchange timestamps compared against server timestamps to analyze latency. The target is absolute accuracy of market data. For a quant or a high-frequency trader, losing data mid-stream can ruin a day and a P&L. algoseek over-monitors rather than explain a gap.
“
Early detection equals fewer nasty surprises. Custom-built tools equal zero blind spots. Dedicated link listeners equal bulletproof data.
No trust in commercial products
Dell’s custom motherboards lock you into their upgrade path. Commercial monitoring software claims to be comprehensive but can’t see congestion on individual server ports. Most co-location providers stick to Dell and third-party monitoring because it’s easy and safe, and procurement teams don’t get fired for buying from a big name. algoseek builds its own because the alternative is paying more for less visibility and replacing servers that should have lasted years.
“
Most colocation providers stick to Dell and third-party monitoring because it’s safe. Procurement teams don’t get fired for buying from a big name. Everyone wins, except the customer footing the bill.
Co-location
Three tiers of co-location
Every tier runs on the same Mercury infrastructure and the same engineering culture.
Tier 1
Hosted Applications
One or two dedicated servers on algoseek’s network, hosted through a partner and fully managed. You get the same Mercury feeds, the same monitoring, and the same engineering culture as enterprise clients, without owning or managing hardware.
Most common
Tier 2
Bring Your Own Server
Ship your own servers, including custom GPU builds. algoseek handles hardware installation, OS setup, networking, power, and remote access. A fiber cable runs directly from the Mercury ticker plant into your machine. You’re right next door to the ticker plant.
Tier 3
Full Custom Co-location
Hardware, software, and market data designed as a single solution. Custom feeds run as add-ons to Mercury’s existing infrastructure, not greenfield builds, which means faster deployment and fewer moving parts. Two decades of knowing what breaks under real-time market data load at scale is built into every design decision.
Every tier includes
Normalized feeds
CTA/UTP, OPRA, CME/CBOT/NYMEX/COMEX, CFE, CBOE Global Indices, OTC Markets
Raw exchange feeds
Native format including raw multicast into cloud via Mercury TCP encapsulation
Custom feeds
VWAP, security status, aggregated bars, scanners, and other computed feeds in real time
Cross-connects
Direct physical connections to brokers, prime brokers, exchanges, and public clouds. 10G/40G/100G.
Private lines
Dedicated connections between algoseek facilities and your HQ, branch offices, or cloud environments
Cloud connectivity
AWS Direct Connect, Google Cloud, Azure, and other public clouds. Hybrid setups supported.
Same Mercury network, same engineering culture. Pick the tier that fits your hardware.
Tier 1 Hosted Applications | Tier 2 Bring Your Own Server | Tier 3 Full Custom | |
|---|---|---|---|
| Hardware | algoseek-managed servers via partner | Your servers, including custom GPU builds | Designed and built end to end by algoseek |
| Server count | 1-2 dedicated | Flexible | Enterprise scale |
| Mercury network access | ✓ | ✓ Direct fiber | ✓ Direct fiber |
| Normalized feeds | ✓ | ✓ | ✓ |
| Raw exchange feeds | ✓ | ✓ | ✓ |
| Custom computed feeds | ✓ | ✓ | ✓ |
| Cross-connects | ✓ | ✓ | ✓ |
| Cloud connectivity | ✓ | ✓ | ✓ |
| Hardware installation | Partner-managed | ✓ algoseek | ✓ algoseek |
| OS setup and networking | Partner-managed | ✓ algoseek | ✓ algoseek |
| Custom feed design | — | — | ✓ |
| Best for | Smaller firms needing co-located access without hardware management | Funds and prop desks with their own hardware and latency requirements | Banks, regulators, and firms with bespoke infrastructure needs |
Data Center + Cloud
Real-time market data into the cloud, at the latency your strategy requires
Public clouds cannot accept multicast traffic natively. Getting raw exchange feeds into AWS or GCP with low latency and no dropped packets is a problem most firms either solve badly or avoid entirely. algoseek has been doing it in production for years, and is one of the only firms that can deliver raw multicast into cloud environments at all.
For latency-sensitive workloads, Mercury streams TCP directly into a compute instance. For workloads that can tolerate it, Kafka sits in the middle. Most clients run a hybrid setup with some infrastructure in the data center and some in the cloud, and algoseek manages both sides.
Cloud delivery options
Lowest latency
TCP stream direct to compute instance via AWS Direct Connect or dedicated fiber
Buffered delivery
Kafka middleware for workloads tolerant of ~100ms additional latency
Hybrid DC + cloud
Co-located servers in Equinix with cloud compute in AWS, GCP, or Azure, managed as one environment
Managed Services
You focus on trading. We run everything underneath it.
Most co-location providers hand you rack space and walk away. algoseek manages the full stack: hardware, networking, monitoring, security, and hands-on engineering from a founding team with more than 140 years of combined experience in trading infrastructure.
24/7 Monitoring
In-house monitoring tools tracking servers, network connections, temperatures, fan speeds, SSD health, and electrical outputs. algoseek monitors for early indicators, not failure. If anything drifts outside expected variance, the team investigates before it becomes a problem.
Remote Hands
Hardware installation, OS setup, deployments, updates, and regular on-site inspections. All work follows the Saturday-only change protocol: scripted in advance, tested, logged, and verified.
Support and Escalation
Support and escalation desk for infrastructure, networking, and data delivery issues. 24/7 monitoring is live; 24/7 support coverage is in progress.
Managed Security
Routine network vulnerability scans, intrusion detection and protection. Private dedicated fiber between data centers.
Architecture
Mercury ticker plant: 3rd generation
The same software that streams real-time feeds to clients also concurrently captures and normalizes the feed to create the historical archive. Written in C++ and Assembly with zero third-party dependencies. Mercury’s built-in redundancy has given clients no downtime since inception.
Region 1
New Jersey: Equinix NY2, NY4, NY5
Region 2
Chicago: Equinix CH1, CH2
Private dark fiber between regions
Exchange Feeds (A + B redundant)
4-way arbitration
Mercury Ticker Plant
3rd generation · C++ and Assembly · Zero dependencies
30TB
OPRA / day
Same write, concurrent outputs
Normalized Feed Low-latency normalized data from all exchanges
Raw Exchange Feed Native format, multicast into TCP for cloud
Historical Archive Written concurrently. Same data shape.
Co-located Your servers (Tier 2) Hosted apps (Tier 1) Full custom (Tier 3)
Cloud AWS Direct Connect Google Cloud Azure / other
Cross-connects Brokers Prime brokers Your HQ
In Production
The hard problems we’ve already solved
US Regulator: Custom OPRA NBBO Regulatory
A US regulator needed its own NBBO for equity options, calculated to a specification that no standard OPRA feed satisfies. The problem is not just knowing the OPRA protocol. OPRA runs roughly 30 terabytes a day uncompressed, and the NBBO has to hold up when volume spikes hit multiples of normal throughput. algoseek built the solution on a Mercury compute grid scaled to absorb those spikes without degrading latency or missing an SLA. To date, it has not missed one.
Custom NBBO Calculation
Mercury Compute Grid
30TB/day OPRA
Zero SLA Failures
Hedge Fund: Raw Multicast into AWS Buy Side
A large fund wanted raw equity SIP (CTA/UTP) and full multicast OPRA inside AWS. The catch: AWS cannot accept multicast traffic. Mercury solves this by wrapping the raw UDP feed into TCP and pushing it over dedicated dark fiber into algoseek-controlled AWS accounts, where the client connects through private link. The entire path is duplicated across New Jersey and Chicago, on both the data center and cloud sides, so the fund can pull any channel from either A or B feeds, from either region, into US-East-1 or US-East-2.
Raw Multicast to Cloud
TCP Encapsulation
Dark Fiber
Dual Region
Prop Trading: Custom Servers to Denmark Buy Side
A Danish hedge fund’s quant trading team and prop traders run on algoseek-built custom servers. The fund receives multicast low-latency SIP data, minute bars, and Nasdaq TotalView via TCP/IP socket. A dedicated connection links the co-location facility to the fund’s on-premise computers in Denmark. An enterprise ArdaDB instance handles market data, machine learning, and trade data for multiple teams.
Custom Servers
Multicast SIP
Nasdaq TotalView
ArdaDB Enterprise
Private Network to Denmark
Global Bank: Index TWAPs Sell Side
A bulge bracket bank needed intraday pricing for its QIS index desk, replacing end-of-day calculations that a significant portion of the US capital markets depends on for portfolio valuation. The data had to meet strict latency SLAs, could not fail, and had to reach both internal teams and external calculation agents who publish official index prices. algoseek deployed Mercury custom feed calculations on regionally redundant infrastructure, outputting to GCS storage. Calculation agents pull any option contract or ticker over HTTP, thousands of requests in parallel, with no integration project on their side.
Custom Data Feed
Regional Redundancy
GCS Output
HTTP Parallel Access
Common questions
The rest of the pipeline
Co-location
Your servers in our cage at Equinix, on the same network as Mercury. Three tiers from hosted apps to full custom builds.
Data Customization
Custom pipelines, computed feeds, data onboarding, and cloud migration.
Data Supplier Solutions
Tools and managed services for data vendors to build, sell, and deliver data products.
ArdaDB
Subsecond SQL queries on the full algoseek historical archive. Included with every data package.
We built the infrastructure behind two US regulators’ OPRA calculations. Let’s talk about yours.
You talk to the same engineers who built the regulator’s OPRA pipeline and put raw multicast into AWS. No sales layer, no hourly billing. One conversation, and we scope the solution.