❌

Vue normale

Reçu avant avant-hiercloud

How Malachyte solves retail’s cold-start problem with managed real-time AI

10 août 2026 à 18:00

What’s the best way to recommend products to little-known users? 

We’ve spent our careers trying to solve this problem for major companies like Spotify and Priceline, and it’s why Sidd founded Malachyte, an AI-powered ecommerce recommendation platform. These days, consumers have come to expect content that feels personalized and relevant, and online services competing for their attention have no choice but to do this exceptionally well.  

Malachyte was inspired by some unique insights into how advanced AI models, and large language models in particular, could be applied in new ways to old challenges like personalization and recommendations. 

As Malachyte set out to win potential customers’ business, we needed secure, scalable, reliable and, above all, leading-edge AI infrastructure to continue building the personalization algorithm we had always envisioned. By utilizing Google Cloud tools like Bigtable and Managed Service for Apache Kafka, Malachyte has been able to help some of its retailers double and sometimes even triple their sales. 

This is the story of how we built it, and the ways any founder can use services like these to start deploying AI foundation models in new ways.

How Malachyte lifted sales for their users 

For Malachyte, the aha moment was discovering that it could use neural networks with attention mechanisms — the same concept powering large language models — to personalize retail search and product pages. This approach is what enables LLMs to derive meaning from the relative order of items in a sequence, in their case the order of words and syllables in a sentence. When it comes to a retail website or app, what Malachyte wanted to capture was the sequence of customer interactions with the site.

1 - Malachyte blog

What if we predicted the next thing a user wants on an ecommerce website just like LLMs predict the next word in a sentence?

A pre-GPT language model might have tried to look at a specific sequence of words or even fragments of words (what we now know of as tokens), but those earlier models wouldn’t examine what happens if the words were in the comparable order but weren’t contiguous or were re-arranged. The breakthrough came — in part through Google’s work on transformers — when LLMs gained the ability to understand complex and long-range dependencies within a sequence of items. 

This more sophisticated method has delivered dramatic results — both for the proliferation of gen AI in general, and for Malachyte’s application of the technology.

To make this work in practice, Malachyte creates a vector of everything known about a visitor when they arrive on a site.  Most users are visiting for the first time, so little is known about them. This is what’s known as the  “cold start” problem. The trick is to use every interaction with a user to refine this vector. Each new addition to the vector, like a click or a query, does two things: it drives a prediction about the next thing the user wants, and it provides more information about the user.  

Malachyte’s platform then updates the user vector and the prediction at the same time. This not only enhances the understanding of the individual user and their preferences, it also improves the overall model with the anonymized user data. With every inference, the context of both the average and the specific shopper grows. 

The company further innovates by not just using attention-based neural networks but combining that with updating user profiles 100 milliseconds at time.

2 - Malachyte Blog

Malachyte’s recommendation and search agents populate the next page’s search results or recommendation carousels based on what users clicked on previous pages.

To be sure, this idea isn’t in itself new. Retailers have long used collaborative filtering recommendations systems to identify similar users and items that required massive sets of interaction history. These models typically required a lot of data, including third-party cookie-based profiles and demographics. 

By focusing on the sequence of interactions in a session, retailers can achieve far more personalization — with less required data or spend — than by focusing only on a user’s profile. As a bonus, retailers can now offer their users more privacy by not relying on long-term cookie data.

This works because of the model structure and multimodal vectors that encode everything they know about a user, including browser data, click history and searches. The output, too, is multimodal: The same model can be applied to on-site search product pages, category pages, and add-to-cart carousels.  

To make this work, each product in the catalog is embedded into the same space as the user vector, which gets updated and subsequently moves the vector closer to relevant products and further from those that aren’t. The neural network computing the embedding is being continuously trained across retailers who work with Malachyte, improving the quality for everyone. The system effectively becomes a data cooperative with each retailer's user helping make the model smarter for everyone.

3 - Malachyte blog vector space - high res

A user session represented as a vector in a space of products.

To make this delivery for every user at every inference in 100 milliseconds, Malachite found real benefits in building onGoogle Cloud’s real-time AI stack.   

With this system, every behavioral event streams into a Managed Service for Apache Kafka cluster. Rather than queuing for a future training job, each event immediately becomes an update to the user’s profile in Bigtable. The Kafka cluster allows the customer’s front-end to persist, so the user session signals quickly with little worry about how they fit into the user vector.  

Bigtable allows Malachyte’s services to look up and update the right user vectors, and it and Kafka operate at the order of 10 milliseconds per step, which allows the entire recommendation loop to complete with no disruption to the user experience. 

4 - Malachyte Blog

The three layer real-time AI architecture: a retailer’s website, Malachyte’s AI models and serving front ends, and context management infrastructure.

In addition to a fast core, a second layer of product catalog updates, inventory signals, and retailer-specific dimensional data keeps product data up to date. This flows through Cloud Pub/Sub, which offers globally accessible REST APIs that enable connections retailers can use without deep integration work. Malachyte agents run on Google Kubernetes Engine (GKE), with model inference on Google Compute Engine (GCE).

5 Malachyte blog

Continuous ingestion of external data, such as product catalog updates, operates through Pub/Sub’s global messaging system.

With its migration to Google Cloud’s AI architecture, Malachyte demonstrated that production AI inference and training are about more than GPUs and storage. They require real-time continuous learning infrastructure that includes a fast key-value store, a streaming layer, and a managed messaging system, all integrated with the foundation model architecture. 

This approach also shows that even a small team like Malachyte’s can have a big impact in an industry. It just needs access to powerful infrastructure and core AI managed services.

Try it for yourself 

Looking to shake up your industry or stay ahead of the competition like Malachyte? Try Managed Service for Apache Kafka, Cloud Pub/Sub, and Bigtable. New customers can receive $300 in Google Cloud credits.

How Target is enhancing retail discovery and cutting database maintenance by 50% with Spanner Graph

4 août 2026 à 18:00

In today’s retail environment, shoppers expect highly personalized product discovery experiences and conversational assistance that feels genuine, natural, and genuinely helpful. Today, successful product discovery is about understanding semantic meaning and the rich, connected relationships between products, categories, and guest intent. It is no longer just about keywords and basic browsing. 

At Target, this work is handled by our Guest Product Confidence platform team. They are responsible for building the features that establish trust and guide purchasing decisions, such as ratings, reviews, and AI-driven digital shopping assistants. An exciting example of this is our Gift Finder chat agent, which we launched during the 2025 holiday season online and in the Target app to help shoppers discover the perfect items through friendly, conversational dialogue.

To deliver real-time personalization and context-rich semantic responses like these at global scale, we identified a critical architectural need to move away from a fragmented data ecosystem toward a unified data platform. We needed a solution capable of supporting high-throughput transactional workloads, highly connected graph relationships, vector similarity search, and full-text keyword search all at once. 

In this post, we’ll explore how we achieved all four with Spanner.

Overcoming fragmented architecture

Previously, Target’s discovery data ecosystem relied on a combination of Elasticsearch clusters for search and inverted indexes, alongside separate NoSQL datastores for our transactional data. While functional, this fragmented architecture presented significant operational and technical challenges.

  • Disconnected context: Keeping separate search, vector, and transactional databases in perfect sync was a constant challenge. Siloed information led to missing context, disconnected attribute relationships, and inconsistent query results.

  • High operational overhead: Managing independent clusters, tuning search indexes, and handling complex, custom synchronization and aggregation logic required intensive manual intervention from our engineering teams.

  • Expansion bottlenecks: Expanding our retail data domains required adding new database collections, maintaining complex joins, and navigating weak transactional guarantees across our discovery and core transactional systems.

  • Siloed intelligence: We lacked the ability to query graph relationships, vector similarity, and keyword search indexes in a single transaction.

To build the next generation of AI-driven guest experiences, we needed to consolidate on one platform.

Building the enterprise ontology on Spanner Graph

We evaluated multiple specialized technologies, including standalone vector databases and niche graph databases. However, adding more single-purpose databases would have only worsened our operational complexity and data synchronization pipelines.

We ultimately chose Spanner Graph to build our enterprise ontology, which is a "graph-of-graphs" paradigm that allows us to construct a massive, generative AI-powered shopping graph.

By unifying our data, we bring semantic data, graph relationships, vector embeddings, and operational transactions under one roof. This establishes Spanner as our single authoritative source of truth for both transactional state and semantic intelligence.

Our high-level architecture now consists of three core pillars:

1. Enterprise augmentation
This layer captures our enterprise retail catalog, aggregates relevant metadata from multiple backend sources, and utilizes generative AI for agentic data enrichment to dramatically improve the quality and depth of the product data we ingest.

2. Unified graph, vector, and search store 
Instead of shifting data across multiple databases, Spanner Graph stores our entity nodes, relationship edges, and vector embeddings in the same database engine. Spanner Graph natively supports multi-hop graph traversals, semantic vector similarity, and full-text keyword queries over our relational tables. Because this multi-model synergy is native, we get strict ACID transactions for absolute correctness across distributed workloads without the need for fragile external sync pipelines.

3. Orchestration and AI layer
This layer powers our conversational guest interfaces, utilizing rich, structured context fed directly from Spanner Graph to ground our LLMs. It extracts highly specific product relationships to power tools like the Gift Finder while governing responsible AI processes and evaluating generated outputs.

A smooth, zero-downtime incremental migration

Transitioning critical search and discovery infrastructure that millions of guests rely on required a cautious, zero-downtime approach. We executed this migration in four structured phases.

  1. Schema and ontology mapping: We defined the specific retail entities, such as products, categories, brands, and guest preferences, and their corresponding relationships within the Spanner Graph schema.

  2. Data integration and parallel replay: We built mutation-based data integrations in a parallel pipeline. This allowed us to continuously replay live transactional updates, apply schema transformations, generate embeddings, and write them directly into Spanner Graph in real-time.

  3. Canary deployment: We gradually shifted live read traffic to the new Spanner Graph-backed platform, validating query performance, semantic accuracy, and database stability under real retail workloads.

  4. Cutover and cleanup: Once performance was thoroughly verified, we fully transitioned all search and discovery traffic to Spanner and deprecated our legacy Elasticsearch stack, entirely removing the maintenance burden of those clusters.

Business impact

By building directly on Spanner Graph, we unlocked measurable technical and business outcomes:

The ultimate GraphRAG foundation: Traditional RAG relies on flat vector similarity, which often misses the structured associations between products, such as matching a toy with its compatible accessories or age-appropriateness. By combining deep graph traversals with semantic vector search in a unified GraphRAG architecture, we grounded our LLMs with highly precise context. This directly improved our recommendation relevancy, enhanced guest satisfaction, and boosted our Net Promoter Score.

Consolidated SQL + GQL interoperability: With Spanner Graph, our developers query structured relational catalog data and connected graph relationships in a single query using standard SQL and GQL (Graph Query Language). This eliminates the need for data duplication, latency, or complex ETL pipelines to bridge these paradigms.

Serverless scalability with zero growth ceiling: Spanner automatically handled massive, unpredictable traffic spikes during peak retail events like Black Friday and Cyber Monday. Spanner's built-in autoscaler dynamically adjusted computing capacity to handle burst traffic during high-intensity, limited-time promotional offers without sacrificing performance.

50% reduction in infrastructure maintenance: By consolidating our transactional NoSQL and search index databases into a single managed Google Cloud service, we eliminated the operational burden of maintaining separate database clusters. Our developers now spend 50% less time on database administration and infrastructure upkeep, allowing us to build and deploy new, customer-facing AI features much faster.

Migrating to Spanner Graph has accelerated our generative AI roadmap, serving as the ultimate proof of what is possible when you build on the right data foundation. 

Want to supercharge your AI apps? It starts with databases with the right graph capabilities at virtually unlimited scale. Discover how Spanner Graph can turn data into action for your organization.

Best Buy scales AI workloads and secures access with Workforce Identity Federation

28 juillet 2026 à 18:00

As Best Buy expanded its use of Google Cloud for advanced analytics and AI, its technology teams faced two significant scaling challenges: Mitigating risk and managing administrative friction when syncing thousands of backend users from Microsoft Entra ID. 

The retailer solved both problems and paved the way for a massive cloud expansion by implementing Google Cloud's Workforce Identity Federation. This direct approach allowed developers to access cloud resources securely using their existing Microsoft credentials without a separate identity store, giving technical leadership confidence that access remains strictly controlled, auditable, and manageable at scale.

Replacing service accounts with direct federation

Best Buy historically maintained complex synchronization pipelines to copy backend users from Entra ID to Google Cloud. Because the organization used Cloud Identity without a Google Workspace deployment, it needed a more direct approach. Previously, Best Buy's Power BI integration with BigQuery relied on service account credentials. 

This pattern can work at a small scale, but quietly becomes a liability as your team grows.

Manually rotating keys for service accounts meant tracking the credentials each team held, and accepting that every key was a potential security vulnerability. Service account keys created daily friction for the Best Buy security and platform teams, and the technical debt compounded as data access requirements grew more complex.

To support tens of thousands of users, Best Buy modernized its identity architecture. The team adopted Workforce Identity Federation to federate existing Entra ID identities directly into Google Cloud. 

Now, when developers access BigQuery through Power BI, they authenticate as themselves using their existing Entra ID identity. They no longer need to rotate keys, worry about credentials exposed in chat messages, or guess who performed an action in the audit log.

The architecture relies on two components working together: Entra ID handles authentication, Workforce Identity Federation brokers the trust relationship between Entra ID and Google Cloud. This federation is stateless on Google's side. It validates tokens at the moment of access instead of syncing user records. Removing the service account key layer greatly reduces the credential management burden.

Architecture

The diagram below shows how identity flows from Entra ID through the Workforce Identity Federation to the services teams use at Best Buy. The key change from the previous approach is the removal of the service account key layer entirely; there is no credential to manage between Entra ID and Google Cloud.

Best Buy architecture diagram no MSFT logo

Identity flows from Entra ID through the Workforce Identity Federation to the services teams use at Best Buy

Key implementation decisions

When implementing this architecture, Best Buy made several important technical choices:

  • Separate provisioning and SSO apps in Entra ID: The configuration follows the Entra ID provisioning and single sign-on (SSO) setup guide. You should separate the provisioning application from the SSO application in Entra ID. Running them as two distinct enterprise apps provides a cleaner separation of concerns; provisioning changes do not affect SSO configuration, and vice versa.

  • Place the automation OU carefully: You need to place the Entra ID provisioning service account in a separate organizational unit (OU) and explicitly disable SSO for that OU. This prevents a bootstrapping problem: If you enforce SSO globally, the provisioning account cannot authenticate to set up the provisioning in the first place.

  • Understand that syncless means stateless on Google's side: Workforce Identity Federation does not create or maintain user records in Cloud Identity. It validates tokens at the moment of access. This makes the architecture viable for Best Buy's target scale, because it eliminates synchronization lag, stale record cleanup, and separate provisioning pipelines.

Secure authentication for developers

For developers, the change was practically invisible. They authenticate once through their corporate Entra ID credentials, and access to BigQuery works automatically, whether through Power BI or direct API calls. The SSO experience matches everything else they access through their Microsoft identity.

For the security and platform teams, the benefits are significant. The attack surface from credential management disappears. Audit logs now show individual users instead of shared service account identities, and you can revoke access quickly based on the enterprise identity lifecycle rather than waiting for manual key rotation.

If you currently manage service account keys for developer access to Google Cloud, moving to Workforce Identity Federation is worth the effort. You gain significant security benefits, and the operational simplicity grows as your team expands. Best Buy is currently scaling this secure access to a broader workforce to power its future retail operations.

Expanding Workforce Identity Federation support

Google Cloud continues to make it easier for all organizations to bring their own identity providers. Recent updates simplify the setup for Ping Identity users and extend access to online billing accounts.

  • Ping Identity integration: If you use Ping Identity, you can follow a new, dedicated setup guide to configure federation. This guide provides step-by-step instructions so you can securely connect your workforce to Google Cloud resources.

  • Online billing support: Google Cloud now supports customers with online billing accounts. You can use Workforce Identity Federation for secure, syncless access without needing an enterprise billing agreement.

Get started

Google Cloud is committed to removing friction from cloud adoption and making it simpler for organizations to secure their environments. To explore these new capabilities and connect your organization's identity provider, read more about how Workforce Identity Federation allows you to federate identities directly, and explore our supported Google Cloud services.

From maintenance to innovation: Checkout's migration to Managed Service for Apache Airflow

22 juillet 2026 à 16:00

Data engineering teams often face a “Day 2” operational reality after building a data platform: the ongoing work of maintaining the orchestrator itself.

For the Data Platform team at Checkout.com, managing a self-hosted Apache Airflow environment on another hyperscaler was consuming time the team wanted to spend elsewhere as server management, patching, and incident response were pulling focus from building pipelines.

By migrating to Managed Service for Apache Airflow (Gen 3), Google Cloud’s fully managed Airflow service, Checkout.com transformed its reliability and cost structure. Here’s how they built a more scalable, cost-efficient, and robust data foundation.

The starting point: self-managed Airflow

Before the migration, Checkout.com ran Airflow on self-managed infrastructure. While functional, maintaining the underlying resources required significant attention. Patching, upgrades, and server management created regular interruptions.

Operational data from the past year illustrates some of the challenges the company was navigating:

  • Reducing operational friction: In its self-managed environment, Checkout.com faced stability challenges, particularly during high-load periods. 

  • Complex dependency management: Upgrading packages and ensuring compatibility was a constant, manual struggle. With Managed Airflow (Gen 3), the company was able to simplify this by handling dependencies at the image level, ensuring seamless compatibility out-of-the-box during routine environment upgrades.

  • DAG sync time: Syncing DAGs to the scheduler took approximately six minutes after deployment to S3, which affected iteration speed.

  • Manual processes: Scaling required manual intervention, and onboarding new teams meant manually creating secrets and variables for dbt.

The solution: Managed Service for Apache Airflow (Gen 3)

Checkout.com’s team migrated to Managed Airflow to offload infrastructure responsibility and take advantage of Google Cloud's managed scalability. The results were immediate and measurable across three areas: reliability, cost, and developer velocity.

checkout-managed-airflow-chart

Dynamic scaling in action

In the previous elastic container service setup, the team allocated the maximum number of workers required for peak loads. This meant paying for peak capacity around the clock, regardless of actual usage.

Managed Airflow provides built-in dynamic scaling, eliminating the need for manual resource management. The environment automatically adjusts the number of workers based specifically on the workload demands. When tasks spike, the system scales up; when they drop, it scales down to save resources. Similarly, moving from fixed provisioning to dynamic scaling reduced monthly costs by an estimated 30%.

Reliability and DAG isolation

Achieving increased stability was a primary driver for Checkout.com’s migration since in the past, a single problematic DAG could affect its entire environment. 

Managed Airflow introduced a number of critical architecture improvements:

  • DAG isolation: Each DAG runs in its own execution environment. If one DAG fails or consumes excessive resources, it doesn’t affect the entire environment.

  • Managed operations: Google Cloud handles patching and upgrades during scheduled windows, removing the need for manual upgrade management.

  • Improved visibility: Integration with Google Cloud Monitoring and Cloud Logging provides clear visibility into task execution. Engineers can now debug issues independently without escalating to the platform team.

Faster developer workflows

The migration also improved day-to-day workflows for Checkout.com’s data engineers.

  • Faster deployments: Using Cloud Storage for DAGs enabled near-instant syncing.
  • Simpler onboarding: Teams no longer needed platform support to create variables before onboarding.
  • Modernizing dbt execution: One of the company’s most significant wins was changing how it runs dbt. Previously, its engineers had to manually install and manage complex virtual environments for every supported dbt version. By leveraging containerized dbt runs, Managed Airflow (Gen 3) eliminates dependency bottlenecks. This ensures complete dependency isolation, allowing teams to run any required dbt model with minimal setup and no manual infrastructure overhead.
  • Environment updates: The company no longer needs to redeploy the entire Airflow environment to add new roles or update Python packages.
  • AI-powered troubleshooting with Gemini Cloud Assist: In a self-managed environment, a failed task often triggered a frantic hunt through fragmented logs and metrics. With Managed Airflow, Checkout.com can initiate a Gemini investigation directly from its Airflow DAG UI in the Google Cloud console. 

Gemini doesn't just provide generic error messages; it generates a scorecard that evaluates different hypotheses with both supporting and contradictory evidence, which can drastically reduce mean time to recovery.

Conclusion

For Checkout.com, the move to Managed Airflow (Gen 3) marked a strategic shift, one that freed its engineers to focus on delivering value.

"With Managed Service for Apache Airflow, we’ve achieved significant improvements in efficiency, scalability, and reliability. Managed infrastructure, automated scaling, faster deployments, and isolated execution environments have transformed how we operate." — Keisi Mancellari, Data Platform Engineer, Checkout.com

With a stable, scalable, and cost-efficient platform in place, Checkout.com is now able to  focus on the future of its data pipelines, confident that its orchestration layer is ready for whatever comes next.

Learn more about Managed Service for Apache Airflow and how it can support your data platform.


Special thanks to the following contributors to this post: Serge Bouschet and Keisi Mancellari

❌