phoenix
phoenixPhoenix - Your AI Assistant
Inactive session will be ended in 24 hours
End Session

Node.js Trading Backend Rebuild

  • Posted:
  • Proposals: 47
  • Remote
  • #4512698
  • Open for Proposals
Joshua A.Talha M.Chintan P.Ziyoddin S.Aviasole T. + 42 others have already sent a proposal.
  • 5

Description

Experience Level: Expert
Estimated project duration: 3 - 4 weeks
I’m overhauling the core of an existing trading bot and need a backend specialist who lives and breathes Node.js. The goal is to replace the current, brittle codebase with a lean, event-driven service that can:

• Ingest and process market data in real time without choking when traffic spikes.
• Fire off automated trade instructions the instant a strategy signals, maintaining millisecond-level latency end-to-end.

Because speed matters more than long-term storage, all transient state should sit in an in-memory database—Redis is my default, but I’m open to something equivalent if you can justify the performance gains.

You’ll design the architecture, write clean, well-tested code, and wire up a solid CI/CD pipeline so updates roll out safely. Deliverables are:

1. Production-ready Node.js backend (TypeScript preferred) that exposes clear REST/WebSocket APIs for strategies and dashboards.
2. In-memory data layer for order books, positions, and pending orders.
3. Exchange adapter module that can be extended to new APIs with minimal friction.
4. Load-tested deployment scripts (Docker/Kubernetes) and documentation that lets me spin up a new instance in minutes.

I’ll review against latency benchmarks, unit/integration test coverage, and clarity of docs before sign-off. If you thrive on low-latency systems and know how to squeeze every last microsecond out of Node.js, let’s talk code.

New Proposal

Login to your account and send a proposal now to get this project.

Log in

Clarification Board Ask a Question

  • CYTNHIA W.

    1: What is the cost of a missed or delayed trade in your business? Understanding your tolerance for stale market data versus execution speed will fundamentally influence whether the architecture should prioritize absolute lowest latency, maximum fault tolerance, or graceful degradation during periods of extreme market volatility.

    2: When an exchange becomes unavailable, rate-limits requests, or delivers inconsistent market data, what should be considered the correct system behaviour: pause trading entirely, fail over to alternative market data sources, or continue operating with degraded functionality? The answer will determine the core resilience strategy of the entire trading engine.

  • VCONN P.

    Hi,

    I have a few questions:

    1. Which exchanges and protocols need to be supported initially (e.g., Binance, Bybit, OKX, Coinbase), and will the service need to connect to both REST and WebSocket APIs?

    2. Approximately what market data volume do you expect (symbols, messages per second, and concurrent strategies), and are there specific latency or throughput targets we should design around?

    3. Will the trading strategies remain separate services that consume this backend through APIs/WebSockets, or do you expect the strategy execution engine to be part of this rebuild?

    4. Is the current backend available for review and partial migration, or are you expecting a complete redesign from scratch while preserving the existing API contracts?

    5. What is your intended deployment environment (AWS, GCP, Azure, bare-metal, or VPS), and do you already have a Kubernetes/Docker infrastructure in place?

    Looking forward to your reply.