In sharing key decisions made on payment gateway systems design and implementation, this document highlights real-world architectural strategies adopted . These use cases illustrate how architectural decision patterns play out in practice, and they are evaluated using a set of established best practices for architecture decision-making.
This first section might be boring, jump to the last section if you want to see the recomendation based on this
In-house vs Open-Source Architecture for Core Services Decision Made: Prioritized building core systems in-house (e.g., payment logic), and using open-source or external tools only for peripheral needs. Identified Architecture Decision Pattern:Use Economic Thinking to Guide Trade-offs — Decision grounded in control and long-term operational efficiency. Reference :https://www.adyen.com/knowledge-hub/design-to-duty-adyen-architecture
Sharding Strategy and Design for Scalable Accounting Systems Decision Made: Designed a custom accounting system and later chose a round-robin database sharding model for flexibility and simplicity. Identified Architecture Decision Pattern:Use Economic Thinking to Guide Trade-offs — Explicit analysis of domain-based vs. round-robin sharding costs and maintenance overhead. Reference :https://www.adyen.com/knowledge-hub/design-to-duty-adyen-architecture-part2
Governing Technology Adoption Through Internal Tech Radar Decision Made: Created an internal tech radar to guide technology adoption and recorded major changes using ADRs. Identified Architecture Decision Pattern:Document Every Decision with ADRs and Run Architectural Spikes to Reduce Uncertainty — TechRadar enabled exploration; ADRs captured rationale. Reference :https://www.adyen.com/knowledge-hub/adyen-tech-radar
Evaluating and Building a Low-Latency Feature Platform Decision Made: Built a feature platform using Feast and Cassandra after evaluating several options and prioritizing low-latency and scalability. Identified Architecture Decision Pattern:Use Economic Thinking to Guide Trade-offs and Run Architectural Spikes to Reduce Uncertainty — Systematically compared trade-offs and tested options. Reference :https://adyen.medium.com/building-a-feature-platform-guided-by-your-ethos-31dfedd3e9c7
Empowering Teams for Architecture Ownership in Reporting Systems Decision Made: Empowered engineers to own design choices, e.g., creating a star-schema database and data warehouse for reporting. Identified Architecture Decision Pattern:Spend Architect Time Where It Matters (Decision Typing) — Decisions delegated to teams with domain context. Reference :https://www.adyen.com/knowledge-hub/the-adyen-way-of-engineering--engineers-as-designers-architects-coders-and-testers
Designing Selective Test Execution Systems with Fail-Safe Fallbacks Decision Made: Built a selective test runner to execute only relevant test cases, with a fail-safe to run all tests if the service fails. Identified Architecture Decision Pattern:Prioritize Failure Prevention with FMEA — Designed fallback paths to mitigate tool failures. Reference :https://medium.com/adyen/test-selection-at-adyen-saving-time-and-resources-c288f4c24e6e
Applying Automated Refactoring Algorithms to Modularize Legacy Systems Decision Made: Applied search-based algorithms to improve modular boundaries and reduce code complexity. Identified Architecture Decision Pattern:Exploratory Refactoring for Long-Term Maintainability — Although not formalized via ADRs or spikes, this reflects an effort to proactively reduce architectural complexity through automated insights. Reference :https://arxiv.org/abs/2102.00701
Designing End-to-End Financial Infrastructure to Reduce Dependencies Decision Made: Built proprietary global banking infrastructure to reduce dependency on third-party banks. Identified Architecture Decision Pattern:Prioritize Failure Prevention with FMEA and Use Economic Thinking to Guide Trade-offs — Risk of third-party failures mitigated, improved settlement speed. Reference :https://www.adyen.com/knowledge-hub/tech-you-can-bank-on
Building Integrated Card Issuing as a Core Platform Capability Decision Made: Launched in-house, fully integrated with its core payments platform. Identified Architecture Decision Pattern:Use Economic Thinking to Guide Trade-offs and Decision Typing — A Type 1 decision with high impact, justified via long-term platform control. Reference :https://www.adyen.com/knowledge-hub/modern-card-issuing
Becoming a Licensed Bank to Unlock Platform Autonomy Decision Made: Obtained a banking license to reduce settlement time, improve stability, and control risk. Identified Architecture Decision Pattern:Use Economic Thinking to Guide Trade-offs and Prioritize Failure Prevention with FMEA — Strategic Type 1 decision with clear financial/risk motivations. Reference :https://www.adyen.com/knowledge-hub/adyen-banking-license
Making ML Platform Decisions Based on ROI and Latency Constraints Decision Made: Built in-house ML infrastructure using proven algorithms with high ROI; avoided deep learning due to cost vs. benefit mismatch. Identified Architecture Decision Pattern:Use Economic Thinking to Guide Trade-offs and Run Architectural Spikes to Reduce Uncertainty — ROI-driven technology selection. Reference :https://medium.com/adyen/how-adyen-does-ai-bf8864b63af7
Experiment-Driven Architecture for Revenue Optimization Features Decision Made: Embedded experimental projects (spikes) into engineering to validate ideas before scaling; focused on measurable business value (e.g., authorization rate improvement). Identified Architecture Decision Pattern:Run Architectural Spikes and Use Economic Thinking to Guide Trade-offs — Experiments guided productization. Reference :https://dwaynegefferie.com/how-adyen-turned-data-into-its-competitive-advantage/
Unifying Real-Time Transaction Intelligence via Internal Graph Architectures Decision Made: Built an internal graph database and streaming platform to unify transaction insights in real-time. Identified Architecture Decision Pattern:Strategic Platform Design for Operational Intelligence — The architecture demonstrates an global platform-first approach, optimizing for observability and fraud response across domains. Reference :https://xenoss.io/blog/how-stripe-paypal-visa-and-adyen-solve-the-toughest-data-engineering-challenges-in-payments
Institutionalizing API Governance and Change Traceability Decision Made: Adopted an API-first architecture with design governance, review boards, and internal recordkeeping for every change. Identified Architecture Decision Pattern:Document Every Decision with ADRs — Maintains centralized documentation of design choices. Reference URL:https://medium.com/adyen/api-first-at-adyen-ecd89d6bdf90
Mitigating Critical Failures in Database Upgrade Pipelines Decision Made: Changed database upgrade process after encountering a rare corruption bug; incorporated new safety checks. Identified Architecture Decision Pattern:Prioritize Failure Prevention with FMEA — Post-mortem analysis led to systemic mitigations. Reference :https://www.adyen.com/knowledge-hub/database-corruption-in-postgresql
Improving Write Throughput with HOT Update-Aware Schema Design Decision Made: Tuned database schema to leverage HOT updates and reduce write load. Identified Architecture Decision Pattern:Tactical Optimization for Storage Efficiency — Though not grounded in a broader architectural framework, this reflects a data-layer-specific optimization to prolong system throughput under high write volumes. Reference :https://medium.com/adyen/fighting-postgresql-write-amplification-with-hot-updates-c8090f329ad6
Zero-Downtime Repartitioning for Large-Scale Relational Tables Decision Made: Developed a strategy for live repartitioning of massive tables with minimal downtime. Identified Architecture Decision Pattern:Operational Migration Strategy for Availability — While it lacks ADR documentation, the method reflects intentional planning around partition state management and system continuity. Reference :https://www.adyen.com/knowledge-hub/efficiently-repartitioning-large-tables-in-postgresql
Designing for Unexpected Data Paths with Default Partitions Decision Made: Implemented a default overflow partition to catch unexpected inputs, preventing data loss. Identified Architecture Decision Pattern:Prioritize Failure Prevention with FMEA — Defensive design to mitigate unhandled scenarios. Reference :https://www.adyen.com/knowledge-hub/how-the-default-partition-saved-the-day
Tuning Checkpoint Strategies to Optimize Recovery Time Objectives Decision Made: Adjusted PostgreSQL checkpoint configurations to reduce crash recovery time. Identified Architecture Decision Pattern:Prioritize Failure Prevention with FMEA — Proactive tuning to ensure system resilience and fast failover. Reference :https://www.adyen.com/knowledge-hub/checkpoint-tuning-for-rto-improvements
Recommendations Based on Analysis
Press enter or click to view image in full size
Architectural decisions shape the success and resilience of software systems. Effective architecture is more than a technical blueprint ,it requires strategic alignment, risk management, and transparent decision-making. The key findings and recommendations below demonstrate how architectural insights translate into actionable steps for technical professionals.
1. Document Every Decision with ADRs
Why: Architectural decisions shape system behavior, incur long-term costs, and constrain future options. Without context, teams risk redoing work or making poor assumptions. Action:
Use Architecture Decision Records (ADRs) to record the context, decision, participants, and consequences.
Keep ADRs short (≤2 pages), version-controlled, and in an accessible central location (e.g., internal wiki).
When decisions evolve, deprecate old ADRs and link to new ones — never rewrite history.
Get Lali Devamanthri’s stories in your inbox
Join Medium for free to get updates from this writer.
2. Spend Architect Time Where It Matters (Decision Typing)
Why: Not every decision deserves deep architectural attention. Misallocating effort leads to bottlenecks or over-engineering. Action:
Classify decisions as Type 1 or Type 2:
Type 1 = High-impact, irreversible → made by architects.
Type 2 = Low-impact, reversible → delegated to dev teams.
Apply Decision Typing at the start of the decision process to streamline prioritization.
Empower teams by improving local decision-making skills, reducing dependence on central architecture.
3. Run Architectural Spikes to Reduce Uncertainty
Why: Many architectural decisions are made with incomplete information. Small investments in exploration accelerate learning. Action:
When unclear, create a time-boxed spike (e.g., 2–5 days) to investigate feasibility or gather quick data.
Define acceptance criteria up front (e.g., performance results, compatibility check).
Discard the code produced — it’s for learning, not production.
4. Use Economic Thinking to Guide Trade-offs
Why: Architectural decisions have cost, value, and risk implications. Technical purity doesn’t guarantee business success. Action:
Apply an economic framework based on 5 dimensions:
Product value, lead time, risk, operating cost, development cost.
Convert trade-offs to financial terms (e.g., cost of delay, ROI of a decision).
Use this to justify architectural paths in business language.
5. Prioritize Failure Prevention with FMEA
Why: Systems fail, often in predictable ways. Resources must target the most impactful failure modes. Action:
Perform Failure Mode and Effects Analysis (FMEA)
List failure modes, rate each by severity × likelihood × detectability.
Use Risk Priority Numbers (RPNs) to focus mitigation/testing.
Update FMEA regularly, it’s a living document.
Involve cross-functional teams (e.g., dev, ops, security) for comprehensive risk identification.
6. Make Fast, Justifiable Estimates with Fermi Estimation
Why: You won’t always have perfect data. But no estimate is worse than a rough one. Action:
Use Fermi estimation to break complex questions into components.
Apply order-of-magnitude approximations (e.g., how many events per second? average data size?).
Communicate estimates as rough guides, not precise truths.
Use this approach when decisions need to be made quickly or with sparse data.
Repeatable Workflow: The Architecture Decision Loop
