GCP News - 2026-08-05

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.

When people think about digital transformation in banking, they often focus on the visible results: mobile apps and new digital services. But there's an invisible infrastructure making all these services possible: APIs. At Deutsche Bank, we recognized that APIs aren't just technical plumbing; they're the nervous system of modern banking. 

A few years ago, our application landscape was dominated by monolithic systems. As we evaluated how to break them into modular, reusable APIs, one thing became clear: we couldn't just decompose our work into APIs — we needed a central API management platform (APIM) to manage what would emerge. We needed something where documentation, security policies, and governance all had to be built in from the start, not bolted on later. 

The question wasn't just how to modernize, but how to best serve our customers and position ourselves for tomorrow's opportunities, especially with emerging technological paradigm shifts. 

Needing a system that was adaptable, scalable, reliable, secure, and AI-ready for the demands of modern banking, we chose Google Cloud's Apigee as our APIM platform. 

Building the backbone: four key capabilities 

Today, Apigee manages our API ecosystem — from open banking APIs connecting us with fintech partners, to the internal microservices powering our various banking platforms, and even the client-facing applications that enable seamless digital experiences such as online banking. 

Here are four important capabilities the platform offers us:

1. Unified governance without sacrificing speed 

Apigee is the foundation of our API catalog. Every endpoint, version, and dependency is documented and discoverable. Development teams find and reuse existing APIs rather than rebuild functionality. We've moved from "Where's that customer data API?" — which took days — to a searchable, real-time catalog accessible to any developer. 

But governance isn't about bottlenecks, it's about guardrails, and with Apigee's policy framework, we automatically enforce standards. OpenAPI specifications, schema validation, and error handling are now baked into the platform. Teams move faster because they work within consistent frameworks. 

2. Security: the employee onboarding analogy 

When thinking about API security, imagine onboarding a new employee. You don't give them access to every system on day one. You follow the least privilege principle, so they get exactly the permissions needed for their role. If they switch departments, their access rights will be updated. If they leave the company, access is revoked immediately. Apigee works the same way for our services and applications. 

When connecting a new service — say, one that accesses customer accounts — we don't open the floodgates. Through OAuth2 scopes and API key management, we define precisely what that agent can access: 

• Read account balances? Yes. 
• Initiate wire transfers? No. 
• Access 90-day transaction history? Yes. 
• Full historical data? Only with elevated permissions. 

Like employee access, these permissions are centrally managed, regularly audited, and instantly revocable. Just as we track employee activity for compliance, Apigee logs every API call to see who accessed what data, when, and why. 

This becomes critical with high-volume automated systems. An automated service doesn't take breaks and can make thousands of calls per minute if misconfigured. Rate limiting and quota enforcement ensure that even when something goes wrong, the blast radius is contained. 

3. Resilience and performance at scale 

Banking doesn't have downtime. When customers check balances at 3 a.m. or markets surge with trading activity, our APIs must respond instantly and reliably. 

Apigee's load balancing and auto-scaling evenly distribute that traffic. Health checks and circuit breakers automatically route around struggling services, and for frequently accessed data, Apigee's caching delivers sub-millisecond responses without hitting backends. 

4. Observability: measuring everything 

Before Apigee, understanding API performance was like assembling a jigsaw puzzle with pieces from different boxes. Now we have unified dashboards showing real-time traffic, error rates by service, usage analytics by consumer, and compliance metrics. This visibility serves operations, product managers who track partner value, and security teams who identify anomalies.

<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="DtBank_Apigee_1" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/DtBank_Apigee_1.max-1000x1000.jpg" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>Apigee provides a central suite of capabilities for managing the full API lifecycle</p></figcaption>
  
</figure>


  </div>
</div>

The path forward 

We built this infrastructure for the API economy, and in doing so, we have also built a strong foundation for the future of digital banking. As the industry evolves, this API-first approach will be critical for integrating next-generation services. 

As digital banking continues to advance, a shift toward intelligent services that can react, predict, and assist in real time is underway. Capabilities such as real-time pattern recognition, predictive insights, and AI-powered assistants are becoming part of everyday digital experiences, with their visibility and impact increasing as adoption accelerates. Each of these capabilities will consume APIs — and they will introduce new requirements: ultra-low latency, high-throughput data flows, and secure orchestration across multiple APIs. 

Because we invested in a flexible API platform with Apigee, we are well-positioned to adapt and optimize our infrastructure for these future needs, rather than having to rebuild it. 

Emerging standards: MCP, A2A, and the future 

The industry is exploring new integration standards. Protocols like Model Context Protocol (MCP) and Google's Agent2Agent (A2A) are interesting because they build on existing API infrastructure. 

Our Apigee-managed APIs are well-positioned to leverage these advancements. For instance, MCP could benefit from our OpenAPI specifications, and A2A could leverage our OAuth2 framework, with both relying on the governance we've built. 

We're also exploring patterns like placing new types of servers behind Apigee proxies to maintain security controls while enabling modern workflows. Our "always-API" pattern ensures that services benefit from centralized management, no matter how they are accessed.

<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="DtBank_Apigee_2" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/DtBank_Apigee_2.max-1000x1000.jpg" />
    
    </a>
  
    <figcaption class="article-image__caption "><p>MCP and A2A are complementary, MCP has a tools and resources focus, while A2A is focused on peer collaboration</p></figcaption>
  
</figure>


  </div>
</div>

The vision: APIs as universal interface 

Every banking capability will eventually be exposed as an API. That’s not because APIs are trendy, but because they're the most flexible, composable, and governable way to share functionality, whether consumed by mobile apps, partner fintechs, analytics platforms, or other automated agents. 

At Deutsche Bank, this shift is already taking shape. The same API foundation that powers our core platforms is now enabling our evolution toward more intelligent, AI-supported services across the bank. That foundation provides the consistency, governance, and scalability needed to bring these capabilities to life, ensuring that as new intelligent services emerge, they can be integrated seamlessly, securely, and at enterprise scale. 

Apigee makes this possible by providing governance that scales across all use cases. It's not about controlling innovation; it's about enabling it safely. 

Lessons learned 

• Invest in excellent documentation. Semantic summaries and clear schemas aren't extras; they're foundational for both developers and AI. 

• Treat security like employee onboarding. Least privilege and role-based access apply equally to APIs.

• Observability is a competitive advantage. Unified analytics enable data-driven decisions. 

• Plan for the future now. Your API management infrastructure becomes your advanced integration layer. 

• Stay curious. Experiment with emerging standards. Flexibility wins. 

Conclusion 

We're at an inflection point. The API economy enabled fintech and open banking. Now, the same infrastructure can serve as the backbone for the next wave of innovation. Our investment in the API platform wasn't just about managing APIs better; it was about building a foundation for whatever comes next. 

As the industry transforms, we’re ready. The future belongs to organizations that move fast without breaking things. For us, that future is powered by Apigee.