Unlocking Real-Time Recommendations: How Noelabs Applied “Monolith” to Alkane Live

In this White Paper Review, Noelabs explores “Monolith: Real Time Recommendation System With Collisionless Embedding Table” , a landmark system paper from ByteDance / BytePlus. We explain the core ideas of Monolith and how we adapted them to improve the recommendation engine that powers our live commerce platform, Alkane Live.

Why Monolith Matters for Live Commerce

Monolith was designed for large-scale, real-time recommendation scenarios such as short-video feeds and online ads. These environments look surprisingly similar to what we face on Alkane Live:

• Thousands of live and upcoming auctions, streams, and drops.
• High-cardinality user and item IDs (streamers, buyers, products, collections, sets).
• Continuous user feedback: views, likes, bids, watch time, cart events, and purchases.

The paper highlights a key limitation of traditional deep learning frameworks: they are optimized for static parameters and batch training. In practice, that means long delays between user actions and model updates. For a live platform, that delay translates directly into lost engagement and lower conversion.

Monolith proposes a different approach: a recommendation system built from the ground up for online training, collisionless embedding tables, and real-time interaction with user feedback.

Core Contributions of the Monolith Paper

The original Monolith system introduces several key ideas that we considered essential for Alkane Live. In particular:

1. Collisionless Embedding Table

In large-scale recommenders, user IDs, item IDs, and categorical features are typically mapped to embeddings via hashing. This can create collisions, where multiple IDs share the same embedding slot. Over time, collisions degrade model quality, especially for rare but important users or items.

Monolith addresses this by designing a collisionless embedding table:

• Each active ID is stored as an independent key in a key-value store.
• Embeddings can be looked up and updated without hash collisions.
• The system scales horizontally by sharding the embedding store.

To keep memory usage under control, Monolith adds two optimizations: expirable embeddings and frequency filtering .

2. Expirable Embeddings & Frequency Filtering

Not every ID deserves a permanent, dedicated embedding. Many users or items will appear briefly and then disappear.

• Expirable embeddings allow rarely used IDs to be automatically removed after a period of inactivity, reducing the table size.
• Frequency filtering ensures that only IDs with enough interactions receive their own embeddings. Very rare IDs can fall back to shared “rare” vectors.

Together, these ideas keep the system scalable while still preserving per-ID personalization where it matters.

3. Online Training Architecture

Monolith proposes a training architecture that blurs the line between training and serving:

• User actions are streamed in real time.
• Embeddings for sparse features (users, items) are updated frequently.
• Dense model parameters (neural network weights) are synchronized at a slower, controlled interval.

This hybrid design allows the model to react quickly to fresh user signals while still maintaining stability and robustness at the dense layer level.

4. Trading Reliability for Real-Time Learning

A critical insight from Monolith is that, under strict latency and freshness constraints, some reliability can be traded for recency. In other words, it can be acceptable to miss a small fraction of updates, as long as the system as a whole stays responsive and up-to-date enough to improve the user experience.

The paper provides empirical evidence that this trade-off leads to better real-world performance compared to purely batch-trained systems.

Our Context: The Alkane Live Recommendation Challenge

On Alkane Live, recommendations power several critical user experiences:

• Which live streams or auctions a user sees first when they open the app.
• Which items are promoted inside a live show (related products, similar lots, or complementary items).
• What upcoming drops and events we highlight based on past behaviour.

The platform faces many of the same challenges described in the Monolith paper:

• Sparsity and high cardinality: New streamers, products (e.g., TCG sets, sneakers, collectibles), and buyers appear constantly.
• Concept drift: User interests shift quickly as trending products and events change from hour to hour.
• Real-time feedback: Bids, watch time, and chat activity are signals we want to learn from immediately, not the next day.

This made Monolith a natural reference point for the redesign of our recommendation stack.

How Noelabs Adapted Monolith’s Ideas

1. From Static Hash Tables to Dynamic Embeddings

Our initial recommendation pipeline relied on a more traditional setup:

• Embedding lookups based on hash-bucketed IDs.
• Nightly or batch-based training cycles.
• Limited handling of rapidly changing item and user spaces.

Inspired by Monolith, we migrated towards a dynamic, collisionless embedding store:

• Each active user, streamer, and item ID gets its own embedding entry in a sharded key-value store.
• Embeddings are updated online as new interactions arrive (view, click, bid, add-to-cart, purchase).
• We maintain a background process that expires embeddings that see no activity beyond a configurable time window.

This dramatically reduced the risk of collisions and allowed us to keep personalization sharp even in niche segments of our catalog (for example, specific Pokémon TCG sets or rare sneakers).

2. Embedding Lifecycle: Promotion, Expiration, and Fallback

Following the spirit of Monolith’s expirable and frequency-filtered embeddings, we now explicitly model the lifecycle of an embedding:

1. Cold start: New IDs start with a shared “cold” or “rare” embedding.
2. Promotion: Once the ID crosses a minimum interaction threshold (e.g., a new seller hosting their first successful auction, or an item gathering enough impressions), it receives its own dedicated embedding.
3. Expiration: If an ID remains inactive for a long period, its embedding is marked as expirable and may be reclaimed, falling back to generic vectors.

This lifecycle keeps our embedding table balanced between specialization and memory efficiency, directly reflecting the strategy outlined in the Monolith paper.

3. Online Updates with Staggered Sync Intervals

We adopted a dual-cadence update mechanism similar to Monolith:

• Sparse parameters (embeddings): updated frequently from streaming user actions, providing fast personalization and responsiveness.
• Dense parameters (model weights): updated on a slower schedule (e.g., hourly or daily), ensuring stability and limiting operational risk.

In practice, this means that when a user suddenly becomes active around a certain category—say, modern Japanese TCG sets or limited sneaker collaborations—our system can adapt within minutes at the embedding level, even if the core model weights have not yet been retrained.

4. Monitoring Freshness, Latency, and Quality

The Monolith paper emphasizes the importance of carefully measuring the impact of online training. We implemented similar monitoring at three levels:

• Freshness: the time between a user action (view, bid, purchase) and its reflection in the embedding store.
• Latency: the time added by embedding lookups and online updates during serving.
• Quality: downstream metrics such as click-through rate (CTR), bid rate, conversion rate, and watch time.

Early A/B tests showed a noticeable uplift in CTR and conversion on recommended items, especially in live auction contexts where behaviour changes quickly. These gains are in line with the improvements reported in independent summaries and analyses of Monolith .

Key Takeaways from Monolith for Practitioners

From Noelabs’ perspective, the Monolith paper provides several practical lessons for anyone building large-scale recommendation systems:

• Stop treating embeddings as static: if your user and item spaces change rapidly, static hash-based embeddings will eventually constrain your model.
• Real-time learning matters: closing the loop between user feedback and model updates can deliver meaningful gains in engagement and revenue.
• Separate sparse and dense cadences: update embeddings frequently, but keep dense parameters stable to avoid chaotic behaviour.
• Use eviction and filtering: not all IDs need their own embedding; focus capacity where you have signal.
• Accept calibrated imperfection: it is often better to have slightly imperfect but fresh recommendations than perfectly trained but stale ones.

What’s Next for Noelabs and Alkane Live

Our work on applying Monolith’s ideas is just the beginning. We are currently exploring:

• Multi-modal embeddings that combine textual, visual, and behavioural signals from auctions and streams.
• Context-aware refresh policies where live shows and high-stakes drops receive faster embedding updates than long-tail content.
• Causal feedback loops that integrate post-purchase satisfaction signals directly into ranking.
• Open research collaborations to share benchmarks, anonymized datasets, and further insights on real-time recommendation for live commerce.

For teams interested in the original research, we strongly encourage reading the full paper on arXiv: Monolith: Real Time Recommendation System With Collisionless Embedding Table .

At Noelabs, this white paper has been a key reference in our journey to build a recommendation engine that truly matches the dynamics of live commerce. By aligning theory with practical constraints, we continue to refine Alkane Live into a platform where the right auctions, products, and creators find the right audience in real time.