RemitTrack

1. Overview

RemitTrack is a real-time exchange rate comparison platform built for the African diaspora. Sending money home is something millions of people do every month, and the difference in rates across providers can be significant. RemitTrack pulls live rates from 15+ Money Transfer Providers, normalises them into a consistent format, and surfaces them in one place so users can see where they actually get the best deal.

Beyond the consumer-facing side, the aggregated rate data serves as a market intelligence and arbitrage risk signal for MTP operators. The platform also has an LLM-powered chat interface that lets users ask questions about rates in plain English, built as an accessibility feature for users who find data tables harder to parse.

2. System Architecture

The platform is a fully Go data platform deployed on AWS. The backend handles all scraping, normalisation, storage, and serving. The frontend is a TypeScript and React application that reads from the API.

Infrastructure runs on AWS EC2 with RDS for PostgreSQL, ElastiCache for Redis, and Kinesis for the streaming ingestion layer.

3. Data Pipeline

The core engineering challenge in RemitTrack is getting fresh, accurate rate data from providers that do not offer a public API. The ETL pipeline handles this in three stages:

• Extract: goroutine-based concurrent scrapers run on a schedule, one per provider, pulling rates in parallel. This keeps the total scrape time close to the slowest single provider rather than the sum of all of them.
• Transform: each scraper outputs a normalised rate record with a consistent schema regardless of how the source structures its data. Currency pair, mid-rate, provider timestamp, and scrape timestamp are all captured.
• Load: normalised records are published to a Kinesis stream. A downstream consumer reads from the stream, applies any final validation, and writes to PostgreSQL. Kinesis decouples the scraping layer from the storage layer, so a slow write to RDS does not back up the scrapers.

ElastiCache sits in front of the API layer and caches the latest rate per provider per currency pair. Most read traffic hits the cache. The database is the source of truth for historical data and alert evaluation.

4. Key Features

• Rate comparison table: live rates across 15+ providers, updated on every scrape cycle.
• Price-target alerts: users set a target rate for a currency pair and get notified when a provider hits it.
• LLM chat interface: a natural-language interface that lets users query the rate data conversationally. Built as an accessibility feature for users who find tables harder to navigate.
• Market intelligence view: aggregated rate data surfaces spread patterns and arbitrage signals across providers.

5. Engineering Trade-offs

• Kinesis over Kafka: MSK has a minimum cost of two brokers regardless of load. At this scale, one Kinesis shard handles the throughput at a fraction of the cost. The trade-off is a 7-day maximum retention window vs Kafka's configurable retention, which is acceptable for this use case.
• PostgreSQL over a document store: rate data is relational and time-series friendly. PostgreSQL's window functions handle spread analysis and trend queries cleanly. A document store would have made these queries significantly more awkward.
• Go modulith over microservices: splitting the scraping layer, API layer, and alert worker into separate services would add deployment and networking overhead that is not justified at this stage. The modulith keeps operational costs low while the codebase stays structured enough to split later if needed.