$ cat ~/projects/mitsubishi-salesforce.mdx
Mitsubishi Salesforce ID
Backend services for Mitsubishi’s dealer sales app, covering lead management, reporting, Salesforce sync, and performance work.
- .NET Core
- Hangfire
- SQL Server
- Redis
- Azure Storage
- Docker
Context
The sales app needed current lead and performance data, including in regions where dealers still had unreliable 3G. The report endpoints were the main bottleneck.
What I built
- .NET Core services for lead ingestion, distribution, and reporting. The endpoints the app called most were read-heavy and cacheable, so the architecture leaned into that from the start.
- SQL Server tuning — added covering indexes on the hot read paths, rewrote a few
SELECT *queries that were pulling unused columns, where the planner was making bad choices. Response times on the reports endpoint went from 2–3 seconds to under 400ms. - Redis caching with a short TTL on the lead list and a longer TTL on the aggregated reports. The cache invalidation strategy was deliberately simple: write through on lead state changes, expire on schedule for reports.
- Hangfire for the recurring background jobs — nightly aggregations, dealer score recomputation, and Salesforce sync reconciliation. Each job is a discrete class with retry semantics.
Outcome
The dashboard stopped feeling slow, and the report endpoint stopped generating support tickets.
What I'd do differently: introduce feature flags from day one. We ended up wanting to gate the new caching layer for specific dealers during the rollout, and shipping it everywhere-and-rolling-back was a risk we didn't need to take.