Strategic Architectural Decision: Option B as the Resilient Bridge to CDA
After testing three competing designs for cross-product transaction history, the team uncovered a mainframe MQ connection constraint that collapsed the favored Option C. This field report captures why Option B became the pragmatic path, how it supports a Q1 2026 Cross-DDA-Account (CDA) launch, and what it unlocks for a utilities-only API future.
Executive Sponsor
Jason — Director of Digital Experience Technology
Technical Lead
Varun — Principal Engineer guiding architectural trade-offs
Product Owner
Sidd — ETU Product Manager orchestrating CDA readiness
Executive Summary
Option B — directing Digital Channels and Search to orchestrate both the DDA Transaction History API for list views and the Cross-Product API for search — is now the interim architecture. Option C, the intelligent router that originally won support, failed due to mainframe MQ connection limits that would have required ~40 new persistent connections. The team is mobilizing consumer alignment, AWS ingestion acceleration, and legacy API decommissioning to launch CDA search and transaction list experiences by Q1 2026 while preserving the long-term vision of a unified, utilities-only API hosted on AWS.
Cross-link to deeper systems thinking: System Thinking: The Foundation of Every Great Empire.
Key Insights
- Option C (router + shared library) collapsed under the weight of mainframe MQ capacity limits, not performance latency.
- Option B keeps Q1 2026 CDA viability alive while nudging consumers toward the future cross-product API.
- AWS ingestion acceleration — compressing batch windows from ~2 hours to 10–15 minutes — is the mitigation lever for data consistency risk.
- Consumer teams must shoulder dual-service orchestration as planned technical debt, balanced by a clear decommissioning roadmap.
- Sam is now the DDA point of contact, streamlining coordination with consumers as they migrate.
Constraints We Cannot Ignore
- Mainframe MQ infrastructure is at capacity; no new direct connections will be approved.
- Batch-mode inconsistencies create a 2-hour window where list and search views disagree on posted vs. pending status.
- Performance SLAs demand <100ms list responses and <150ms search responses even when traffic doubles with CDA.
- Consumer bandwidth is the critical path; without Digital Channels and Search commitments, timelines slip immediately.
Detailed Breakdown
1. Strategic Context
CDA functionality is a top-tier commitment: by Q1 2026, customers must search and review transactions across DDA accounts in a unified experience. The urgency is powered by three drivers — customer experience parity, digital transformation mandates, and an explicit push to retire technical debt. Fragmented APIs (DDA v1–v4, Cross-Product for search) and unexpected list view usage by the Score Card team exposed resilience gaps, especially during SOR failovers. Legacy constraints now intersect with the digital transformation goal of building a cloud-native, API-first banking platform.
Related playbook: DDA Going Primary Dashboard Strategy for monitoring the readiness runway.
2. Option Review
Three viable patterns emerged. Each pushes us toward the Cross-Product API target in different ways, and each demands a conscious tolerance for technical debt so we can hit the end-to-end testing milestone on schedule.
Option A: System-of-Record Integration
The most resilient path embeds DDA system-of-record logic directly into Cross-Product. It creates a single utility surface with built-in failover.
Tradeoff: Highest complexity and change scope; would delay consumer migration timelines well past the forcing milestone.
Option B: HTTP Orchestration Model
Consumers orchestrate HTTP requests across DDA Transaction History for lists and Cross-Product for search. It is achievable within the current timeline, respects existing SOR integrations, and remains the realistic fallback if other approaches stall.
Tradeoff: Requires coordinated consumer migration and disciplined retirement of dual-call logic after rollout; we knowingly accept this debt to land the milestone.
Option C: Library Routing Bridge
Embeds a shared DDA library inside Cross-Product to route list traffic without a network hop, aligning strongly with the eventual utility fabric.
- ➕ Acts as a consumer migration bridge toward the target state.
- ➖ Adds 30–40ms latency and requires MQ connectivity that Mainframe/SOR partners rejected.
- ➖ No new consumer connections, yet only viable if teams roll off legacy API versions while rolling onto the shared library.
| Evaluation Lens | Option A | Option B | Option C |
|---|---|---|---|
| Approach Summary | Cross-Product absorbs SOR failover capabilities for a fully resilient utility. | Digital Channels and Search maintain orchestrated HTTP calls across existing APIs. | Cross-Product hosts the DDA library to dynamically route list and failover traffic. |
| Strengths | Ultimate resilience; single surface for all consumers once complete. | Timeline-safe, leverages proven integrations, keeps consumer autonomy while we migrate. | Aligns with target state, minimizes long-term dual-service debt, simplifies onboarding. |
| Key Tradeoffs / Risks | Engineering lift exceeds milestone window; risk of scope creep and performance regression during build. | Operational tech debt from dual-call logic until consumers retire legacy flows; requires strong governance. | Latency penalty of 30–40ms, MQ dependency rejected by Mainframe/SOR, contingent on simultaneous consumer roll-off from old versions. |
| Connection Model / Consumer Migration Impact | Direct SOR integration; demands coordinated cutovers from every consumer before go-live. | HTTP request choreography; straightforward fallback if other options stall and manageable within current teams. | Library routing bridge; requires MQ (not approved) and mandates roll-off of legacy API versions as part of the roll-on plan. |
Architecture history fans can cross-reference DDA API Migration: V2 to V3 to see how incremental modernization succeeds.
The upcoming end-to-end testing milestone is a forcing mechanism for these decisions. To meet this deadline, we are prepared to accept additional tech debt.
Next Steps for Consumer Migration
- Begin contacting consumers now about rolling off old connections and retiring unsupported API versions.
- Assess and document what each API provides to guarantee feature parity as consumers migrate to new experiences.
- Build a decision tree for adoption so every team has a clear runway:
- Digital Channels → Cross-Product API.
- OSC Servicing → Transaction History API.
- Ensure roll-off plans double as roll-on support for the new orchestration paths.
Decision Tree: Adoption Guide
A lightweight visualization that guides consumer teams toward the correct API while migrations progress.
Update: Option C Latency, Connections & Feasibility
- Performance testing confirmed an added 30–40ms latency penalty compared to the HTTP choreography in Option B.
- Mainframe/SOR partners formally rejected the MQ connectivity required to embed the DDA library inside Cross-Product.
- The team aligned on a fallback: if Option C cannot satisfy infrastructure constraints, remain on Option B without hesitation.
- Any future revisit of Option C must pair a roll-off from legacy API versions with a synchronized roll-on to the shared library.
3. Post-Meeting Discovery
Hours after the technical review, the mainframe team confirmed that no additional MQ connections would be provisioned. Because each of the ~40 Cross-Product instances would need its own persistent MQ link when embedding the DDA library, the elegant Option C became untenable. The path snapped back to Option B, and the focus shifted to consumer enablement and resilience testing.
4. Customer Impact Window
During batch windows (currently ~2 hours), DDA list views read from the SOR and display posted statuses, while Cross-Product search relies on Cassandra/ODS and can show those same transactions as pending. Around 10% of customers who search after viewing their list could experience inconsistency, potentially fueling support contacts and eroding trust.
The mitigation plan accelerates AWS data ingestion to shrink batch windows to 10–15 minutes per bank and sequences processing bank-by-bank to reduce simultaneous customer impact. This workstream, originally slated for early 2026, is pulled into late 2025 to align with CDA expectations.
Implementation Guide: Option B in Motion
- Week 1–2: Run a quad alignment with Digital Channels, Search (Tanya's team), ETU Product, and Architecture to confirm bandwidth, acceptance criteria, and integration timelines. Document decision trees so new consumers default to the right API.
- Month 1–3: Build the consumer orchestration layer, integrate the DDA shared logic for batch-specific scenarios, and execute performance tests covering failover and normal mode. Stand up monitoring that flags list/search divergence.
- Month 4–12: Accelerate AWS ingestion improvements, migrate DDA data pipelines, and plan the retirement of DDA History v1 & v2 to liberate legacy MQ connections.
- Beyond: March toward utilities-only resilience — APIs relying solely on internal utilities and local data stores — and prepare the DDA migration to AWS to eliminate future dependencies.
Cross-link the testing blueprint: End-to-End and API Testing for ETD for validation patterns worth reusing.
Risk Radar
- Data Consistency: High probability during batch windows, mitigated by AWS acceleration and proactive customer messaging.
- Timeline: Medium probability — slips occur if consumer teams cannot prioritize Option B changes.
- Technical Debt: Moderate — dual-service orchestration adds complexity, requiring disciplined follow-through on the utilities-only roadmap.
- Performance: Watch for SLA breaches as cross-account traffic scales; caching and query optimization remain on standby.
Alignment & Dependencies
Success rides on coordinated execution:
- Digital Channels orchestrate dual calls without degrading UX.
- Search Service Experience team ensures query performance meets <150ms SLA, resolves ownership of list functionality, and confirms development bandwidth.
- ETU team sequences AWS ingestion and API decommissioning with mainframe partners.
- Architecture governance tracks technical debt and future consolidation checkpoints.
Stakeholder Communication & Contingencies
Transparent communication keeps confidence high while Option B ships:
- Executive Updates: Emphasize Option B as a pragmatic bridge, highlight AWS acceleration progress, and reinforce the utilities-only north star.
- Product Alignment: Co-design customer messaging about temporary data mismatches, run joint testing sessions, and publish shared KPIs for data consistency, latency, and satisfaction.
- Contingency Plan: If Digital Channels or Search cannot deliver dual-service orchestration in time, reopen Option A despite the heavy lift; institute monthly readiness checkpoints.
- Performance Degradation Playbook: Keep cache tuning, query optimization, and capacity headroom reviews ready should Option B introduce latency spikes.
Post-Meeting Follow-Up
Meeting Takeaways
- MQ constraints formally block Option C; Option B remains the dependable baseline.
- Sam is confirmed as the DDA point of contact to coordinate consumer migration details.
- The decision tree will steer teams toward Cross-Product or Transaction History APIs based on channel fit.
- Accepting short-term tech debt is preferable to missing the end-to-end testing milestone.
Next Actions
- Launch consumer outreach to schedule roll-off of legacy API versions.
- Document feature parity checkpoints between existing APIs and new flows.
- Publish the decision tree with adoption guidance in partner channels.
- Track readiness weekly against the end-to-end testing forcing mechanism and flag emerging tech debt.
Strategic Implications
- Infrastructure Awareness: Early validation of mainframe constraints is mandatory for every modernization initiative.
- Cross-Team Coordination: Architectural wins demand synchronized delivery across Digital Channels, SSE, ETU, and mainframe partners.
- Pragmatic Engineering: Option B proves that intentional technical debt can preserve strategic momentum when governed.
Resource Stack
Dive deeper into working documents, prototypes, and AI collaborations fueling this decision:
API Strategy Decision Infographic
Visualizing the path to a resilient transaction history service
The Core Challenge
Engineer a resilient transaction history service that stays highly available through batch processing without overloading mainframe systems or sacrificing the performance SLAs that power dashboard and card experiences.
The Path to a Decision
Three options were tested. The final selection was driven by infrastructure realities — specifically MQ connection ceilings — and performance guardrails.
Option C: "Smarter API"
Cross-Product would route simple queries to DDA Transaction History.
❌ Rejected
Added 30–50ms latency and masked backend complexity without solving MQ limits.
Refined C: Library Approach
Embed DDA library to skip the network hop.
❌ Deal-Breaker
Required ~40 new MQ connections — impossible under current mainframe capacity.
Option B: The Way Forward
Consumers split responsibilities across DDA History v4 and Cross-Product.
✅ Selected
Feasible within timeline once consumer teams commit to dual-service orchestration.
Final Decision Analysis
Option B remains the only path that satisfies resilience, timeline, and infrastructure realities.
Key Blocker: Performance Impact
Additional latency from Option C threatened search responsiveness; the library approach solved speed but not MQ saturation.
Action Plan & Strategic Outlook
🎯 Immediate Priorities
- Engage Consumer Teams: Secure Q1 commitment from Digital Channels and Search for Option B delivery.
- Decommission Old APIs: Free mainframe capacity by sunsetting DDA History v1 & v2.
- Clarify Onboarding: Publish a decision tree so new consumers adopt the correct API path.
🚀 Strategic Outlook
- Protect Performance SLAs: Maintain sub-150ms responses as traffic scales.
- Manage Technical Debt: Treat Option B as a bridge to a unified Cross-Product API.
- Plan for AWS Migration: Target DDA migration to AWS to eliminate mainframe dependencies.
Reflection Questions
- What signals will tell us that consumer teams are overburdened and Option B needs added support?
- How do we communicate temporary data inconsistencies to customers without eroding trust?
- Which additional AWS investments could compress batch windows even further than the 10–15 minute target?
- What governance rituals ensure that the utilities-only target state stays front-and-center once CDA ships?
- Where can we safely experiment with new MQ alternatives ahead of the DDA migration to AWS?
Atomic Notes
- Timeline: CDA search + list parity due by Q1 2026; AWS ingestion acceleration pulled into late 2025.
- Instances: ~40 Cross-Product service instances would each require an MQ connection under Option C.
- Customer Touchpoint: ~10% of users viewing lists also hit search, magnifying inconsistency risk.
- Performance: Targets remain <100ms (list) and <150ms (search); <200ms for cross-account queries.
- Governance: Architecture reviews must catalog Option B technical debt and schedule consolidation checkpoints.
- Team Focus: Digital Channels, Search, ETU, and mainframe operations form the critical delivery pod.
- Long Game: Utilities-only resilience is a 12-month evolution culminating in a unified AWS-hosted Cross-Product API.
- Document Ledger: Classified as Strategic – Internal Use; next review in December 2025; distributed to executive leadership, engineering leadership, and product management.
Success Metrics
- Delivery: Q1 2026 CDA launch achieved, milestone burndown reliable, and partner commitments honored.
- Technical Performance: Response times remain within SLAs, batch-mode availability holds, and divergence alerts stay below threshold.
- Customer Experience: Satisfaction scores improve, support tickets about inconsistent statuses decline, and cross-account search adoption rises.
- Operational Excellence: Legacy API maintenance effort drops, mainframe connections free up as v1/v2 retire, and AWS ingestion milestones close on schedule.
Key Success Factors & Strategic Recommendations
- Cross-Functional Collaboration: Maintain weekly syncs across Digital Channels, SSE, ETU, and mainframe operations.
- Technical Execution Excellence: Enforce rigorous performance, resiliency, and data integrity testing for every drop.
- Strategic Patience: Keep the utilities-only target state visible so interim complexity is temporary.
- Accelerate AWS Investment: Fund ingestion improvements aggressively to shrink the inconsistency window.
- Strengthen Architecture Governance: Formalize quarterly reviews to measure debt retirement and consolidation readiness.
- Invest in Coordination: Standardize playbooks for multi-team architectural changes to reduce future drag.
- Monitor & Iterate: Pair telemetry with customer feedback loops to adjust quickly after launch.
Medium-Style Cross Links
Trace the broader transformation narrative:
- Infographic: The 5 Forces Shaping Everything — macro forces framing digital bets.
- Smart Nudges Implementation Deep Dive — lessons on orchestrating AI workflows.
- Projects Portfolio — current experiments across Cruz AI.