Charting Platform Architecture & Improvement Plan

@jayantkumar314

As a Senior Software Engineer with over six years of experience, I have successfully built websites from the ground up whilst also providing viable solutions to complex API-driven projects. For a project of this magnitude, my proficiency in Python and PHP - two languages I've consistently used during my career - makes me exceptionally well-placed to tackle your specific problems: candle gaps, date/session gaps, discrepancies between historical and live feed, and ensuring the congruency of timeframes in relation to user expectations. My storage optimization approach would involve sensitive use of Redis, DB/files for historical data as opposed to hot cache, while recommending an appropriate retention strategy. While remaining loyal to your constraints of not inventing OHLC and being broker-agnostic at the edges, my 'end-to-end flow' plan will resolve the issue of missing gaps versus intentional breaks, plus chart healing after a WS disconnect ensuring no spikes. Ultimately, I am invested in providing transformative solutions; be it with dynamic rate limits or restoring graphs to functionality after a widespread drop. I complement my skill set with an entrepreneurial spirit; offering realistic yet effective solutions even if we run into complications. Choose me for this assignment and together we’ll navigate through complexities thanks to my robust AWS hosting platform experience - leaving you with reliable architecture backed up by sound implementation plan.

@techmadigital

Hi, I can review your TradingView datafeed architecture and deliver a concrete plan for historical plus live candle delivery. I would map client to gateway, candle builder, session calendar, cache, backfill and relay, then define one canonical bar identity so REST and WebSocket merge cleanly. I would cover first load, live forming bars, scroll-left history, reconnect gap fill and symbol or resolution switches, with detection and healing rules for candle and session gaps. I have built MT5 and broker API pipelines with SQLite candle stores, WebSocket feeds and dashboards. I can show similar systems on chat. Thanks, Nikhil

@Jennycreation

Hello Sir, I have already worked on many **cryptocurrency trading systems, automated trading platforms, and exchange API integration projects**. I can also show you demos of my previous work. I am a full-time freelancer with **17+ years of experience** in software development, trading automation, and financial API integrations. My relevant experience includes: * Cryptocurrency trading platforms * Binance and Bybit API integration * MT4 and MT5 trading automation * C#-based copy trading software * Arbitrage trading systems (Binance ↔ Bybit) * Automated order execution (Buy/Sell/Square Off) * Portfolio and position management * Margin and risk management features * Real-time market data integration * Trading bots and strategy automation I have already developed a **C#-based Copy Trading Software** where trades from a master account are automatically copied to multiple child accounts. I have also built **arbitrage trading systems** between Binance and Bybit using their official APIs. In addition, I have developed trading platforms using **Zerodha Kite API, Alice Blue API, Angel One API, and Profitmart API**, including features such as order placement, position management, square-off, margin calculation, and automated trading execution. I have also implemented strategy automation using **AmiBroker CSV integration**. I can start working immediately and deliver a secure, scalable, and reliable trading solution based on your requirements. Please contact me in private chat so we can discuss your project in detail. I will be happy to show you **live demos and examples of my previous trading projects**. Looking forward to working with you. Thanks & Regards, Sanjay

@nikkibraiam

Hi, I'm a backend architect with real experience designing low-latency, real-time data systems (WebSocket streaming, microservices, market-data pipelines). I understand the real challenge here: the hard part isn't the REST history call or the WebSocket feed individually, it's the seam between them — handing off cleanly from the historical "tip window" to live ticks without gaps or duplicate candles, while correctly modeling IST market-hours gaps (overnight/weekend/holiday) on the timeline so the chart never misrepresents a session boundary as missing data. What I'll deliver: ✓ Clean architecture doc for historical + live candle delivery via your own API layer (browser never talks to the broker directly) ✓ Explicit strategy for the REST-to-WebSocket handoff with no gap/duplicate risk ✓ Session-gap handling model for IST market hours ✓ Concrete plan to fix the production gaps you're currently seeing I work fast (7 days), don't ask questions mid-project, and deliver exactly what you need—nothing less. Let's build this right.

@nakabirik

Hi, I am Muheebwa. I understand you need an architecture and implementation plan only, not development, for a TradingView based Indian markets charting platform where historical REST and live WebSocket data feed the chart, and the main issues are candle gaps, session and date gaps, stitching bugs between hist and live, timeframe aggregation consistency, and WS reconnect backfill. What usually matters most here is the bar identity rule, since hist and live should produce the same bar by symbol plus resolution plus bucketStart in IST, and every stitching bug you describe traces back to the two sides disagreeing on which bucket a bar belongs to. A common issue in TradingView datafeeds is that the front end commits the live bar as time moves, while hist only commits on request, so the last bar time differs and TradingView either shows a hole or redraws the bar when hist arrives. My approach would be to propose a canonical candle model with a single bucket rule and a session calendar as the source of truth, define merge and upsert rules so hist and live agree on the same bar, then map the flows for first load, live subscribe, scroll left, reconnect, and symbol change, with a gap detection and healing plan, a storage split between hot cache and durable history, and a risk checklist with acceptance tests. Looking forward to hearing from you.

@ayushsoftcare

Drawing from my extensive experience as a senior engineer, I'm confident that I can provide a robust architecture for your charting platform and an actionable plan to address the shortcomings in the current setup. My familiarity with TradingView and its advanced charting library along with my expertise in working with market-data APIs will prove invaluable. Being highly performance-oriented, I'll ensure streamlined historical and live candle delivery architecture that result in near-flawless UX, eliminating issues like missing/duplicate bars and incorrect handling of session breaks and gaps. Continuity is key in your domain and understanding this well, I'll propose an architecture that optimizes your existing API layer, allowing it to seamlessly communicate with the broker while maintaining the structural integrity of brokering functionalities such as rate limits, late ticks, etc. My approach would be to architect components like gateway, candle builder, session calendar, cache/storage mechanism, backfill job and relay ensuring high reliability while accommodating history loads, real-time websocket updates and bar forming rules.

@indreshpnk

Hello, I understand you need a senior architecture review and implementation plan for a TradingView-style charting platform handling broker historical data, live WebSocket candles, session gaps, stitching, aggregation, and recovery. The goal is a clean, broker-agnostic architecture plan focused on production reliability rather than development. Here’s what I can provide: A clear architecture diagram covering TradingView datafeed, API/WS gateway, candle builder, session calendar, cache/store, broker history/live, and backfill. A canonical candle model with bucket identity, timezone/session rules, hist-live merge/upsert logic, and multi-timeframe consistency. End-to-end flows and concrete solutions for gaps, reconnects, backfills, symbol/resolution changes, storage, migration phases, risks, and acceptance tests. I bring over 4+ years of experience in Python, APIs, databases, JavaScript, and backend architecture, with a strong focus on reliable data pipelines, REST/WebSocket integrations, caching, and scalable systems. Just to clarify a few things: Which broker API and current storage/cache technologies are you using? Do you already have sample historical payloads and WebSocket message shapes available for review? Please come to the chat box to discuss more about your project. Best regards Indresh Kushwaha

@mukeshcodyy

Hi, I can provide a focused architecture review and implementation plan for your TradingView-style charting platform, specifically addressing historical/live candle delivery and production stitching issues. 1. Architecture Review: Design a broker-agnostic flow covering TradingView datafeed → API/WS gateway → cache/store → historical/live broker sources, including candle builder, session calendar, relay, and backfill components. 2. Candle & Session Model: Define canonical `symbol + resolution + bucketStart` identity, timezone/session rules, aggregation consistency, and safe merge/upsert/replace logic between historical and live data. 3. Production Fix Plan: Cover first load, live subscriptions, scroll-left history, reconnect/gap healing, symbol/TF changes, broker rate limits, late ticks, and intentional vs missing session gaps. 4. Deliverables: Provide an architecture diagram, 1–2 pages of detailed design, storage recommendations, migration approach, risks, and practical acceptance tests without taking on development work. I’ll keep the design focused on production reliability while preserving the clean TradingView datafeed contract. Let’s chat and review your current hist/WS payloads and production gaps.

@ronakkataria1

One of your own acceptance tests will fail on real NSE data: "weekend doesn't invent Saturday candles". NSE traded on Saturday 1 Feb 2025 and Sunday 1 Feb 2026, both Budget days, and Muhurat trading opens a one-hour session on Diwali, a holiday. Weekday rules plus a holiday list drop those bars or flag the holiday as a gap. So the calendar comes from the exchange's trading-day list, and resolveSymbol passes it to TradingView through session_holidays and corrections. The rest hangs off one rule: a bar's identity is symbol + resolution + bucket start, built by one candle builder for both paths, so hist and live can't disagree on a boundary. The forming bar is provisional. When its bucket closes, the broker's bar replaces it, so you never invent OHLC. After a WS drop, backfill runs from the last committed bucket before live resumes. Two smaller causes behind your symptoms: TradingView expects daily bars at 00:00 UTC of the trading day, not IST midnight, and quietly shifts bars it thinks are misplaced. And a getBars reply that includes the bar at "to" repeats it, which is where scroll-left duplicates start. You get the diagram, candle model, five flows, gap plan, storage split and acceptance tests, phased so production stays up. Plan only, as you asked. Background: low-latency streaming architectures, and ML trading and forecasting systems. My rating here is 5 out of 5. Does your broker's history API return today's candles, including the one still forming? Ronak

@zaryabk83

Hi, I'm Zaryab. I can deliver this as an architecture and consultation engagement — no development. My plan covers: - **Target architecture** — Client (TV datafeed) → our API/WS gateway → candle builder + session calendar → Redis hot cache → durable hist store → broker hist + live. Broker-agnostic edges so the provider can be swapped later. - **Canonical candle model** — bar identity as `symbol + resolution + bucketStart` (bucket open time, IST), same identity produced by both REST and WS, with clear upsert/replace rules for the hist-live seam. - **End-to-end flows** — first load (tip + deeper hist), live subscribe + forming bar, scroll-left history, WS reconnect + gap fill, symbol/resolution switch. - **Gap fix plan** — detection (missing vs session break) using a session calendar, healing via broker backfill or 1m warehouse re-derivation, and what the TV datafeed must guarantee to avoid holes and wrong day separators. - **Storage** — Redis for live tip, DB/files for deep history, retention and rebuild strategy. - **Risks + acceptance tests** — your checklist, plus a phased migration note if a rewrite is needed. Deliverable: architecture diagram + 1–2 pages of prose, ready to review. Quick questions before I lock the design: are you storing any historical data yourself today, or is everything fetched from the broker on demand? And is the WS relay already in place, or still direct from broker? Best, Zaryab

@abdullahs850

I can review your TradingView + broker architecture and provide a clear plan covering candle stitching, live/historical data, sessions, caching, backfill, WebSocket recovery, and acceptance tests

@Ashoksahu001

As an experienced software engineer, I have worked on numerous projects involving complex data flows and real-time processing - skills that will be critical in delivering a solid architecture plan for your charting platform. Throughout my 12+ years of experience, I have built platforms using technologies like React.js, Flutter, and PHP that were responsible for handling massive amounts of data efficiently. Notably, I've also developed trading platforms that required comprehensive data aggregation and smooth user-experience in real-time environments. My plan for your charting platform comprises an architecture diagram covering all components from gateway to storing the broker hist and live data using technologies relevant to the task at hand, guaranteeing both efficiency and performance. Additionally, I understand the vital importance of data consistency, timezones, and session calendars to produce meaningful charts. With this in mind, my design will ensure your platform is reliable by considering scenarios like reconnects or late ticks without creating gaps or spikes in chart data. Recognizing your need to stay broker-agnostic and keep the TradingView data feed clean, I propose a solution that utilizes our own aggregation/cache while ensuring existing design isn't invalidated. Working within these constraints with seamless migration plans if needed is one of my specialties. On top of all these technical expertise elements I bring to the table,

@Tradeware

Hi, I can provide the architecture review and implementation plan only—no development required. I’ll map the full TradingView data path from datafeed → API/WS gateway → candle builder/session calendar → Redis/cache + historical store → broker adapters. The plan will define a canonical candle model, IST/NSE session handling, deterministic timeframe aggregation, historical/live stitching and upsert rules, reconnect/backfill logic, and broker-agnostic interfaces. I’ll also provide phased migration steps, gap detection/healing strategy, storage recommendations, sequence flows, risks, and concrete acceptance tests for symbol/TF switching, holidays, WS drops, late ticks and duplicate/missing candles. Keywords: TradingView, WebSocket, OHLC, Market Data Architecture, NSE, Candle Aggregation, Redis, Backfill, API, System Design

@giuliofuerte

Your brief identifies the main risk clearly: reconciling the REST history edge with live updates while preserving exchange-session boundaries. I build production CMS booking platforms and API-integrated systems with payment, availability, and reliability constraints. I propose an architecture-only engagement: a broker-agnostic dataflow diagram; canonical candle identity and merge rules; first-load, live, scroll-back, reconnect, and symbol/resolution-change flows; gap detection and repair; storage and phased-migration recommendations; and an acceptance checklist. After reviewing anonymized history/WS samples and the current datafeed flow, I will deliver the concise 1–2 page plan with focused clarifying questions within 3 days. No implementation is included. Are the IST calendar and broker corrections the source of truth for finalizing a bucket?

@anmolm82

Hi, I can deliver a clear architecture plan addressing exactly the failure modes you've described — candle gaps, session/date handling, hist-live stitching, and reconnect healing. My approach: Target architecture: Diagram covering TV datafeed → API/WS gateway → candle builder → cache (Redis for live tip) → durable store (deep hist) → broker-agnostic adapter layer Canonical candle model: Bar identity as (symbol, resolution, bucketStart) in UTC internally, session-calendar-aware bucketing for IST hours; explicit merge/upsert rules so hist and live never disagree on the same bar End-to-end flows: First load (tip + deep hist), live subscribe/forming bar, scroll-left backfill, WS reconnect gap-fill, symbol/resolution switch — each with sequencing to prevent races Gap detection/healing: Session-calendar-driven gap classification (real gap vs. holiday/weekend), backfill from broker REST vs. 1m warehouse derivation Storage: Hot cache vs. durable store split, retention strategy, rebuild path Acceptance tests: Concrete checklist (no missing 5m bars, WS-kill recovery without spikes, no invented weekend candles) Deliverable: 1-2 page architecture document + diagram, scoped purely as consultation — no development, as specified. Budget: ₹1,400 fixed. Timeline: 3 days. Happy to review sample hist/WS payloads before finalizing the design.

@nabeeli18

Greetings I understand you're seeking a senior engineer to review and propose a clean architecture for your TradingView-style charting platform, and I have completed similar projects in the past. I can help address your architecture needs, focusing on delivering a solid plan to fix the existing gaps in production, ensuring reliable historical and live candle delivery while enhancing the user experience. My approach will involve creating a target architecture diagram and detailing end-to-end flows, addressing gaps, and ensuring consistent timeframes. I bring experience in designing robust data architectures and implementing reliable APIs, perfectly aligning with your project requirements. I’d love to chat about your project and suggest a follow-up discussion to explore this further. Regards, Nabeel Ismail

@B1zt

Hi, Most of the gaps you describe come from one missing rule: historical and live data do not agree on what a bar is. Once every bar has a single identity (symbol, resolution and bucket start in IST, checked against a trading calendar), the holes, duplicates and weekend candles become easy to spot and fix. What I would deliver: - An architecture diagram from the TradingView datafeed through your API, cache and store to the broker, with each component's job spelled out - The bar model: time convention, session calendar, and clear rules for when live and historical data touch the same bar - The five flows written out: first load, live forming bar, scroll left, reconnect with gap fill, and symbol or resolution change - A gap plan covering how to tell a missing bar from a real market break, and how to heal it without spikes - Storage advice on what lives in Redis and what is durable, plus an acceptance checklist and a phased rollout that keeps production online INR 15,000 for the written plan and one review call, delivered in 7 days. One question: do you keep your own 1m history, or does every higher timeframe come straight from the broker? Happy to go through your sample payloads on the call before I lock anything in. Thanks, Bhagya

@lavanyat14

Hi Bengaluru team, reviewed your TV Charts + broker hist + live WS + IST 09:15-15:30 gaps. Built similar — MedStore AI Backend — FastAPI + MySQL + Redis hot cache + background workers + JWT — sub-120ms search, 5000+ products. Architecture: TV datafeed (onReady/resolveSymbol/getBars/subscribeBars) → API Gateway (FastAPI) → Candle Builder (ID: symbol+res+bucketStart IST open-time) → Redis (tip/forming) + TimescaleDB (1m warehouse) + Parquet (cold hist) → Broker Adapter (REST+WS) + Session Calendar (NSE holidays) + Backfill Job. Broker-agnostic. Model: Bar time = bucket open IST. Hist + live same bucket ID. Merge: upsert on bucketStart, live last tick wins forming, hist overwrites on reconnect, no dup. Flows: First load = tip Redis + deeper hist DB parallel. Live = forming bar aligned. Scroll-left = paginated de-dupe. Reconnect = WS drop 2min → backfill missing buckets heal no spike. Symbol change = unsubscribe flush tip. Gaps: Detect via calendar (weekend/holiday vs true hole). Heal via broker backfill or derive from 1m warehouse. Guarantees: no missing 5m 10:00-10:30, no Saturday candle, no teleport. Storage: Redis TTL 1 day hot, TimescaleDB durable 1m, Parquet cold. Tests: no missing intraday bar, WS heal, weekend collapsed, 1m→5m match. Q: Share hist payload + WS tick shape + one bug sample? Broker — Zerodha/Angel/Upstox? Deliverable: Diagram + 2 page plan + migration + checklist — 7 days — ₹10,500.

@ElStormeo

For INR750, I'll review one broker/data path from your diagrams and anonymised payloads and deliver one conceptual diagram plus up to two pages covering flow, storage, phased fixes and acceptance checks. My relevant background includes DayTradeScans and production engineering at SolarReviews. The review can address adapters, candle reconciliation, exchange calendars, history/cache and API/WebSocket datafeeds. Includes one written clarification round; code, deployment and exhaustive repository investigation remain excluded. Please provide the broker/API version and an example broken sequence. Delivery: 2 working days after access and scope confirmation. I'm new to Freelancer, but I bring 12+ years of commercial software experience. This is a reduced introductory price while I establish my record here. I'd appreciate the opportunity to earn your trust through the work. Storm