Strategic Architectural Decision: Option B as the Resilient Bridge to CDA
As DDA goes primary and customers expect a seamless transaction history across channels, we needed to determine the best path forward for delivering consistent data without overwhelming our mainframe or fracturing the consumer experience. This field report documents the options we evaluated, the constraints we uncovered, and the rationale for the architectural path we ultimately aligned on.
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
Problem Statement
We must enable unified transaction history while DDA goes primary, meet the CDA delivery window, and keep the mainframe stable. Assessing the best path forward demanded that we weigh latency, mainframe MQ connection limits, and consumer change management so that the solution we choose accelerates—not derails—the march toward a single cross-product "uber" API.
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 the interim architecture we are moving ahead with. Option C, the intelligent router that originally won support, faltered when we uncovered the mainframe MQ connection ceiling and recognized the latency it would add under load. We still view Option C as the eventual best decision once the infrastructure gap closes, yet Option B keeps us on schedule, advances the DDA-going-primary initiative, and preserves momentum toward a utilities-only API hosted on AWS.
Cross-link to deeper systems thinking: System Thinking: The Foundation of Every Great Empire.
Voices from the Architecture Review
Leaders across engineering and product weighed in on how each option supports the long-term Cross-Product API vision. Their takes informed the balance between near-term feasibility and the strategic target state.
“I think cross product is kind of like the digital Uber API, but we may need a different API for ops or access pattern, depending on what they want to do.”
Jason on the overall strategy
“Calling another API is just so unnecessary, adding this latency is not an entire pattern in general.”
Varun on the library approach
“I think this is a bridge to getting consumers on the cross product, and then in the background, we can evolve towards our target state. It's dead, but it's also like a nudge towards the right direction and just a debt that we can accept.”
Jason on managing technical debt
“We need to look at who's on v1 and who's on v2 because they're essentially booted up in production, and if it creates a connection and it's not used, that just takes away from our ability to stand up the new version of the API.”
Dan on API connections
“I think if we're truly trying to push towards the target state, rather than having folks call DDA transaction history and call cross product, this gives us more control at the end of the day.”
Sidd on the proposed Option C solution
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
Embed DDA system-of-record logic directly into Cross-Product so every experience calls a single utility. This is the purest expression of the long-term vision.
Pros
- Ultimate resilience with one API responsible for list, search, and failover behavior.
- Eliminates duplicate consumer orchestration paths at the cost of a larger initial build.
Cons
- Engineering scope exceeds the immediate milestone and jeopardizes CDA commitments.
- Requires synchronized cutovers from all consumers, increasing operational risk.
Option B: HTTP Orchestration Model
Keep DDA Transaction History and Cross-Product as separate services while Digital Channels and Search orchestrate calls to both. This was designed as the pragmatic bridge.
Pros
- Delivers within existing timelines with minimal backend disruption.
- Respects known SOR integrations and allows incremental consumer migration.
Cons
- Creates temporary dual-call logic that must be retired post-launch.
- Requires disciplined governance to ensure all consumers roll off older API versions.
Option C: Library Routing Bridge
Embed a shared DDA library inside Cross-Product so it can route list traffic without a network hop. This progressive disclosure of intelligence inside Cross-Product initially emerged as the favorite.
Pros
- Aligns tightly with the target-state "uber" API vision.
- Reduces consumer complexity by consolidating orchestration in Cross-Product.
Cons
- Introduces 30–40ms of latency during routing, impacting SLA headroom.
- Requires ~40 additional MQ connections that mainframe partners cannot support today.
- Demands concurrent roll-off of legacy API versions while the library goes live.
| 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. |
Why Option C Slipped
Option C carried early momentum because it concentrated intelligence in Cross-Product and looked like the cleanest route to a single "uber" API. That enthusiasm cooled once the infrastructure reality set in: standing up the library would require roughly 40 additional MQ connections and would still add 30–40ms of routing latency. Mainframe partners confirmed that the MQ headroom simply does not exist, so the favorite option instantly turned into an infeasible one.
Alignment on the Path Forward
We aligned on using the DDA-going-primary initiative to keep marching toward Cross-Product as the future "uber" API. Option C remains the architectural north star once MQ capacity and latency concerns are solved, yet Option B is the next best decision and the one we are executing. The MQ discovery forced us to pivot, and now Option B lets us honor CDA milestones while continuing to retire older integrations.
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
Other takeaways include disciplined consumer migration, version management, and clearer guidance for who uses which API.
- Begin contacting consumers now about rolling off old connections and retiring unsupported API versions to reduce persistent mainframe MQ load.
- Treat every roll-out of refreshed APIs as a simultaneous roll-off of prior versions so connection counts trend downward.
- Assess and document what each API version provides to guarantee compatibility and feature parity as we plan future iterations.
- Build a decision tree for adoption so every team has a clear runway:
- Digital Channels → Cross-Product API.
- OSC Servicing → Transaction History API.
- CDFO → Transaction History API (until cross-product capabilities expand).
- 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.