The problem
A customs brokerage firm was running a legacy system built in Visual FoxPro 7 to sync with the web services of ARCA (the Argentine customs authority). To handle their client load, they had to run 20 parallel processes at the same time.
The results were painful:
- Each full sync cycle took more than 2 hours to complete.
- The 20 processes together consumed gigabytes of RAM.
- When something failed, no one knew until a client complained.
- Recovery from any crash required manual intervention, sometimes at 3am.
The firm needed a system that was fast, reliable, and self-monitoring — one that could keep up with modern operations without requiring constant attention.
The solution
I designed and built a new system from scratch on modern .NET, replacing the 20 legacy processes with a single background service installed on Windows. Two modules run in parallel inside the same process, doing what previously required a small server farm.
Module 1 — Talking to ARCA
Instead of running processes in a loop hoping for the best, the new system uses a proper scheduler that fires jobs periodically for each type of service. Each job checks all active clients in parallel while respecting the timing rules the authority requires.
Key improvements over the legacy system:
- Modern authentication: cryptographic signing done natively instead of relying on external tools and batch scripts.
- Smart token caching: from hundreds of authentication tokens per day down to just two per service every 12 hours.
- Rate limiting per client: automatic handling of the authority's cooldown windows, so one slow client never blocks the others.
- Controlled parallelism: 10 clients processed at once by default, adjustable without touching code.
- Automatic recovery: transient network errors trigger retries with exponential backoff, invisible to operators.
Result: what used to take 2 hours now completes in under 10 seconds per service, using about 300 MB of RAM total.
Module 2 — Processing customs XML files
Customs brokers receive XML files from the customs system with the full details of every operation. The old approach was to write custom code for each field. Adding a new field meant a new deployment.
I built a declarative mapping engine: instead of code, mapping rules live in a database table. Adding a new field is a single INSERT, no deployment needed. The engine supports substrings, constants, contextual values, and fallbacks.
All writes happen inside a single atomic transaction, so a partial failure never leaves the database in an inconsistent state. If a file arrives before the corresponding data from the web service, it goes into a retry queue that reconciles automatically every 15 minutes.
Result: ~3,500 accumulated files processed in minutes. New files now process in seconds.
Making it self-monitoring
A system that runs 24/7 needs to tell you when something is wrong. I integrated the platform with the WhatsApp Business Cloud API: when the database goes down, a backlog grows too large, or a client has repeated failures, the system automatically messages the responsible team.
It also sends recovery notifications when things go back to normal, with built-in anti-spam so no one gets flooded during a long incident.
On top of that, the service is installed with automatic startup and native recovery actions in Windows. After three consecutive failures, it triggers a script that flags the next restart for special handling.
Impact
- Sync time: from 2 hours to under 10 seconds per service.
- Memory footprint: from several GB to ~300 MB total.
- Failure detection: from "wait for a client complaint" to "WhatsApp message within seconds".
- Adding new XML fields: from a full development cycle to a single database insert.
- Recovery: from manual intervention to fully automatic.
The system is currently in production, processing customs operations 24/7 for the firm.