Day 48 — Order Submission: Engineering the submit_order API Endpoint
Think of today as the moment a car goes from being designed on paper to actually driving on the road. Until now, you have been building the engine parts. Today, you connect them — and the system places its first real order. But before we write a single line of the correct solution, let us look at exactly how this goes wrong.
Part 1 — The Wrong Way (and Why It Matters)
Every beginner’s first attempt at order submission looks something like this:
# THE ANTI-PATTERN — will silently destroy a live account
import requests
def submit_order(symbol: str, qty: int, side: str) -> dict:
return requests.post(
"https://paper-api.alpaca.markets/v2/orders",
json={"symbol": symbol, "qty": qty, "side": side, "type": "market", "time_in_force": "day"},
headers={"APCA-API-KEY-ID": API_KEY, "APCA-API-SECRET-KEY": SECRET_KEY},
).json()
Four lines. Looks clean. Works fine in a notebook during testing. And will cause serious damage the moment real money is involved. Here is a precise breakdown of how it fails.
Failure 1 — Duplicate Orders on Retry
Your signal fires. The HTTP call gets a 504 Gateway Timeout from Alpaca’s edge server. Your retry logic kicks in and submits again. You now have two separate BUY orders for NVDA sitting in the exchange queue. There is no client_order_id on either request, so the exchange accepts both — it has no way of knowing they are duplicates.
At $580 per share, a 100-share signal just became a 200-share position with no awareness on your side. This is not a theoretical risk. It happened at a mid-size fund in 2019 during an AWS us-east-1 partial outage.
Failure 2 — Blocking the Event Loop During a Spike
A single requests.post() call blocks the calling thread for 30–200ms while it waits for a response over TCP. If your strategy is polling 50 symbols every second, that one blocking call stalls every downstream signal calculation waiting behind it. During a volatility spike when everything is moving fast, you submit 12 orders in 800ms — and miss 6 exit signals because the event loop was frozen, waiting on Alpaca’s load balancer. This is not a latency problem. It is an architecture problem.
Failure 3 — No Pre-Trade Validation Leads to Margin Calls
Alpaca’s /v2/orders endpoint will happily accept a market BUY even if your buying power is $0.00. It books the order as pending_new, then rejects it a few seconds later. But because there is no rejection listener, the position tracker still thinks you are long. The risk system sees a clean slate and lets the next signal through. That spiral has no obvious stopping point.
Failure 4 — Float Arithmetic Breaks Buying Power Checks
>>> 0.1 + 0.2 == 0.3
False
>>> 58.15 * 100
5814.999999999999
Using Python float for any monetary calculation introduces small rounding errors that compound invisibly across hundreds of orders per session. The fix is to use Decimal with explicit precision everywhere. No exceptions.
Part 2 — The Architecture We Are Building
