Sprouts.ai ABM Platform

Sprouts.ai is a cutting-edge Account-Based Marketing (ABM) platform designed to help B2B companies identify, engage, and convert high-value accounts. As the lead architect, I was responsible for building the core infrastructure that powers the platform's data intelligence capabilities.

The heart of the platform is the Golden Database - a sophisticated ElasticSearch-powered repository containing millions of person and company records. I designed and implemented a flexible filter framework that translates complex user queries into optimized ElasticSearch queries, enabling users to segment and target accounts with precision.

One of the most challenging aspects was building the Waterfall Enrichment Engine from scratch - a high-performance system that enriches contact and company data across 25+ third-party providers. It is a *field-level* waterfall: to fill a specific attribute such as a verified email or phone, it walks providers in a configurable, tenant-overridable priority order and stops the moment that field is both satisfied and verified. A provider returning an email is not enough - the value passes through verification before it is accepted, because a wrong email is worse than no email. The engine reaches roughly 80% verified enrichment coverage, meaning around 80 of every 100 submitted contacts come back with verified details.

Each provider plugs in behind a factory and canonical-mapper SPI, so the framework owns the flow and a connector owns only its vendor-specific mapping. Adding a provider is a thin plug-in rather than a change to the engine. Throughput reached about 250,000 enrichments per day at an average of 2-3 seconds end-to-end per contact including verification, running on Kafka partitioned consumers with bounded async fan-out across named thread pools.

The interesting constraint is that throughput is bounded by the providers' rate limits, not by the engine. So I built an API orchestration layer with multi-API-key rotation over distributed per-key rate limiting, implemented as a single atomic Redis Lua script shared across every consumer pod - a local counter would collectively blow each provider's global limit. When a key is throttled the limiter raises a rotation signal and the request hops to the next key rather than sleeping; only when the whole pool is saturated does it fall back to a timed delay on the key that frees up soonest. That lets capacity scale horizontally with available provider quota.

Two production hardenings were worth the effort. A Redis-Cluster CROSSSLOT failure had been silently disabling distributed limiting because the limiter's two keys were landing on different cluster nodes; hash-tagging the key names fixed it. And a capped fail-open jitter means a Redis outage degrades throughput instead of parking the enrichment thread pool. I also kept the long-running orchestration deliberately non-transactional, so a slow external HTTP call never pins a database connection.

On cost, an ElasticSearch "already-have-it" short-circuit with a freshness check satisfies a field from stored data before making a paid API call - around 30% of enrichments now resolve from cache at no provider cost, and that share compounds as the corpus grows. Raw provider payloads are retained so mapping bugs or vendor schema drift can be reprocessed without re-purchasing data. For enterprise customers, BYOK lets them run enrichment on their own provider contracts and quotas, with platform-versus-customer key attribution stamped on every record for billing.

I also built the central Credit Management System that handles credit allocation, usage tracking, and billing across the entire platform. Currently, I'm architecting a multi-channel notification system that will support push notifications, Slack integrations, and email alerts for real-time user engagement.