Mitsubishi Salesforce ID

Context

Mitsubishi's dealer network runs on a Salesforce-backed sales pipeline. The mobile app used by dealers needed real-time visibility into leads, performance metrics, and reporting — and it had to feel fast even on the 3G connections dealers get in some regions.

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 app started feeling instant on the dashboard the dealers open 30 times a day. More importantly, the slow-report problem stopped being a support ticket.

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.