Every StaxInvesting article tagged system design · 4 posts.
4 articles
Most explanations of trading software are either marketing abstraction or engineering documentation. This is the middle: what actually runs where, which of the three parties can do what, what an API key really is, how the software updates itself without you redeploying, and — the part nobody writes — exactly what happens when your instance dies, your broker goes down, or you revoke access.
A TradingView webhook is not a connection to your broker. It is an unauthenticated HTTP POST from a third party to a public endpoint you own, delivered with a three-second budget and no guarantee it arrives at all. Everything that determines whether it works lives in what you build behind that URL. This is the full reference: the alert-to-order flow stage by stage, how to design a payload, the security model TradingView does not give you, and the failures that only show up in production.
Automation is the most misunderstood word in retail trading. It is not a strategy, not an edge, and not a way to make money while you sleep — it is a transmission system that executes rules you define, faster and more consistently than you can by hand. This is the complete technical guide: the signal-to-fill pipeline, the architecture that carries it, the engineering failure modes that break real systems, and an honest accounting of what automation genuinely solves and what it leaves entirely untouched.
Environment variables are read once, at boot — changing a setting means a redeploy and a process restart. For any long-running service that can't afford a bounce, that's a problem. Here's how to move from env-var config to a database-backed ConfigManager backed by PostgreSQL and Redis, so settings update live and the process picks them up without stopping — including the parts that bite: consistency, validation, failure modes, and what should never live in a config table.
