Recommendation Blocks
Built the company's product recommendation feature from nothing. Designed a three-tier trust ladder so merchants could start with high certainty and graduate as confidence grew. Most who tried it ended up on the fully live tier.
Node.js · Redis · MongoDB Atlas (multi-region) · ClickHouse · Google Pub/Sub
My Role
Context
ConvertCart's merchants are SMBs running e-commerce stores. They need product recommendations but are risk-averse: wrong recommendations hurt conversion, cost credibility. If a feature feels unreliable or slow, they turn it off and never come back. Building merchant trust is the core product challenge.
Problem
ConvertCart doesn't have recommendations. Competitors do. Our merchants need this feature, but want low risk. How do you get a merchant to enable a feature that could hurt their business if it fails? How do you measure success without visibility into merchant behavior? How do you serve real-time ranking across five regions under 200ms?
- No recommendations
- Merchant anxiety about feature risk
- No multi-region serving
- Merchants want to increase AOV
- Market expects recommendations
- Feature adoption = retention signal
Architecture
Three-tier ladder: Manual (CSM hand-picks products for each store), Automated (rules-based: "people who bought X also bought Y"), Smart (live behavioral ranking). Each tier uses different computation: Manual is static, Automated is batch-refreshed, Smart is real-time Redis-backed. Merchants graduate as trust builds. Multi-region MongoDB for serving, ClickHouse for analytics.
CSM hand-picks products
↓ (trust grows)
AUTOMATED TIER
Rules-based ranking (batch)
Affinity algorithm, hourly refresh
↓ (trust grows)
SMART TIER (most merchants)
Live behavioral ranking
Redis cache · 5-region replicated
200ms p99 latency SLA
Key Decisions
- Three-tier trust model, not one
Merchants graduate in order, not all-or-nothing. Manual tier proves value, Automated tier proves reliability, Smart tier proves sophistication. - Computation matched to tier, not uniform
Manual is static, Automated is batch, Smart is live. Allows gradual adoption without building all three systems at once. - Redis-first for latency, durability trade-off
In-flight sessions lost on Redis failure is acceptable for recommendations; would not accept this for orders. - Read replicas trade freshness for speed
Few seconds of lag serving non-US shoppers beats permanently slow blocks. Asymmetric failure modes.
Execution
Adoption Measurement
Built tier progression tracking. Monitor which merchants enable, which tier, how long they stay on each. Found that 80%+ of merchants who tried Smart tier stayed on it — the proof that it works.
Conversion Attribution
Built linkage from orders to specific recommendation blocks. This is what let merchants see ROI. Became the core proof point in sales conversations.
Multi-Region Challenge
Building 200ms p99 across five regions: US, EU, APAC, India, Brazil. MongoDB replication acceptable latency, but Redis replication lag caused stale rankings. Solution: eventual consistency model with fallback to cached results on replica lag. Merchants accepted slightly older data over slow pages.
Impact
Why It Mattered
- Recommendations became first-party product, not third-party tool.
- Conversion attribution proved ROI to merchants.
- Feature expanded into multi-channel personalisation.
- Retained merchants longer and increased ARPU.
Scale
80%+ adoption on hardest tier · 5 regions · 200ms p99 latency · zero downtime during rollout · merchants generating revenue through recommendations
What I'd Change Today
What I'd Preserve
The three-tier model was right. Trust-based adoption beats feature-push adoption.
What I'd Change
Would invest more in A/B testing infrastructure early (Smart tier had minor bugs that could have been caught faster). Also would have built more merchant-facing dashboards to show performance data in product, not just to sales/success.