Architecture Philosophy
Transformation is shaped by architectural decisions.
The success of large systems is decided by the soundness of the architectural decisions they are built on. We make those decisions at the start of the project, on principles tested in the field many times over.
Seven architecture principles
The principles below are the design rules we apply on our projects and whose results we measure.
- 01
Event-driven, asynchronous, isolated
In services that trigger each other through synchronous REST chains, a single fault spreads across the whole system. We separate modules such as reconciliation, capacity, pricing and planning through event streams; if one service stops, the others keep running. This is the approach that ended cascading outages in an airport operation and keeps 70 million transactions a day stable in a payment infrastructure.
- 02
API-first and partner-oriented
We design every capability first as a standard, documented, versioned API; the interface comes after. With a developer portal and sandbox, onboarding a new partner drops from months to days. As the partner ecosystem grows, the architecture does not grow — it simply gets used.
- 03
Business rules in one place
A business rule embedded in the mobile app means days of app store approval for the smallest change. We move rules to a channel-independent orchestration (middleware) layer: even if core banking changes, the mobile app is unaffected; a campaign update takes minutes instead of weeks.
- 04
Componentize, reuse, replicate
Coding every screen from scratch and building every app from scratch is architectural debt. With a Core SDK (integration and workflow management) and a UI SDK (a component library assembled by configuration), 2,581 screens can be produced from 133 designs; a new app stands up in 3–4 weeks instead of 5–6 months.
- 05
Observability and data are part of the architecture
Systems that cannot be observed in production cannot be managed. End-to-end tracing (traces, metrics, logs), an analytical data layer and real-time dashboards are the output of the first sprint, not the final phase of the project. The same data layer makes the organization AI-ready for forecasting and optimization models.
- 06
Compliance is a design input
Banking regulations, capital markets information systems communiqués, payment services legislation, KYC/AML requirements, information security standards and country-level central bank rules. We design these as part of the data model and the flows, not as a checklist added afterwards.
- 07
Lossless migration, zero downtime
Changing infrastructure while live traffic, active merchants and ongoing reconciliation processes are in place is one of the highest-risk kinds of transformation. We run it in staged waves, with dual-write periods, rollback plans and a full reconciliation check at the end of each wave. The payouts, commission and authorization profiles of thousands of merchants are carried over in full.
Architecture patterns: how we apply them
Principles set direction; patterns determine implementation. Below is a summary of the technical decisions that recur across our projects, with their rationale.
01Migration and transition patterns
- Strangler (incremental retirement)
- The legacy system is not switched off in one go; capabilities move to the new platform slice by slice while a routing layer shifts traffic gradually.
- Dual-write + reconciliation
- Both systems are fed during the transition; automated reconciliation reports differences at the end of each wave, and a wave closes only at zero difference.
- Change data capture (CDC)
- Changes in the legacy database are turned into an event stream; new services stay current without coupling to the legacy system.
- Rollback plan
- Every wave has a defined rollback procedure and decision threshold; rollback is part of the plan, not an exception.
- Profile-based data migration
- Record-level validation and sampling audits for business-critical data such as merchant, payout, commission and authorization profiles.
02Data consistency and event processing
- Outbox and idempotent consumers
- Event publication is atomic with the database transaction; consumers produce the same result even if they receive the same event more than once. “At least once + idempotency” instead of “exactly once”.
- Distributed transactions with sagas
- In multi-service workflows (allocation → payment → delivery), compensating steps are defined up front; no distributed locks.
- Event-sourced core
- Where auditability is mandatory (savings finance pool ledger, lottery draws, journals), state is derived from the event ledger; the audit trail is the data itself, not a by-product.
- Deterministic calculation
- Financial figures are produced in a single calculation service with a single rounding rule; a figure differing between channels is made architecturally impossible.
03Multi-tenancy and isolation
- Isolation models
- Shared schema / schema per tenant / database per tenant; a decision matrix based on regulation, data volume and operating cost.
- Tenant context
- Identity, authorization, rule set and brand identity travel in the tenant context; code does not fork, configuration diverges.
- Noisy-neighbor control
- Per-tenant quotas, rate limits and priority classes; one tenant’s load does not affect another’s SLA.
04API management and partner integration
- Versioning
- APIs versioned per consumer; a backward-compatibility commitment (N-x support window) and a deprecation calendar.
- Contract-first design
- The API contract is written and approved before implementation; the sandbox is generated automatically from the contract.
- Bounded contexts and anti-corruption layer
- External systems’ models do not leak into the core; adapters translate at the boundary.
05Observability and operability
- SLO-based management
- SLI/SLO definitions for every critical flow (p95/p99 latency, error rate, transaction completion); alerts are tied to error-budget burn, not to thresholds.
- Correlated tracing
- Traces, metrics and logs are joined by a single correlation ID; a transaction’s journey from channel → gateway → core → ERP is followed on one screen.
- Operational runbooks
- Every alert has a defined response procedure; end-of-day, reconciliation and batch jobs are idempotent and re-runnable.
- Cost awareness
- Log volume, retention period and sampling strategy are design decisions.
06Security and compliance architecture
- Segregation of duties
- The preparer ≠ approver rule is enforced in software for critical transactions; the authorization matrix is auditable.
- Identity and access
- Role-based access, short-lived tokens, service-to-service authentication, secret management.
- Data classification
- Personal and financial data are classified by purpose; deletion requests are met through anonymization that does not conflict with retention obligations.
- Immutable audit trail
- Append-only records; integrity through timestamps and a hash chain.
07Performance and capacity
- Capacity modeling
- A resource plan derived from target transaction volume, peak factor and growth projection; measured thresholds instead of “we will scale later”.
- Load and resilience testing
- Load tests close to the production profile before go-live; dependency outage, latency injection and back-pressure scenarios.
- Back-pressure and queue management
- At peak, accepted load is limited and queued; the system slows down but does not fall over.
Architecture assessment: what we look at
The architecture assessment report, the output of the first meeting and the discovery phase, covers the headings below. A CTO who knows what the report contains can pin down the scope in the very first meeting.
Output
Risk map, target architecture options (benefit–cost–risk), recommended transition order and first-wave scope.
| Area | What we examine |
|---|---|
| Context map | Systems, bounded contexts, integration points, data ownership |
| Coupling and dependency | Synchronous call chains, single points of failure, cascading outage risks |
| Data architecture | Consistency model, duplicated calculations, reconciliation gaps, data quality |
| Scalability | Bottlenecks, stateful components, barriers to horizontal scaling, capacity thresholds |
| Cost of change | Business rules embedded in code, missing configuration layer, release cycle time |
| Observability | Monitoring coverage, alert quality, blind spots, post-incident analysis capability |
| Security and compliance | Authorization matrix, audit trail, data classification, regulatory gaps |
| Organization | Alignment of team boundaries with system boundaries, skill gaps, ownership |
A four-phase working model.
Every phase has a defined output; the next phase builds on it.
- 01
Discovery and Architecture Analysis
In-depth interviews with senior and middle management and key staff; mapping the current infrastructure architecture, application development processes, database structures and integration landscape.
Output
Architecture assessment report, risk map and benefit–cost synthesis.
- 02
Target Architecture and Roadmap
Design of the target architecture; definition of platform, component and integration standards; tying short-, medium- and long-term investment areas to a concrete program plan.
Output
Target architecture document, program plan, budget and schedule.
- 03
Build and Staged Transition
Parallel agile teams, continuous integration, test automation and staged go-lives. Measurable acceptance criteria and reconciliation at the end of each wave.
Output
Platform running in production, technical documentation, operational runbooks.
- 04
Value Partnership and Continuous Improvement
Enterprise maintenance under SLA, regular release updates, input into backlog prioritization and knowledge transfer to the organization’s team. On long-running projects, a “creating value together” model with a flexible, certified expert pool.
Output
A continuously current platform, measured SLA, competence built up in the organization’s team.
Engagement models
Every project differs in its level of uncertainty and its duration; the commercial model is chosen accordingly. We define each model explicitly; on many projects they are used in sequence: discovery → fixed-scope first wave → value partnership.
Discovery and architecture assessment (fixed duration, fixed fee)
Starts with a defined duration and output: architecture assessment report, risk map, target architecture options and first-wave scope. Independent of any decision to continue; the report belongs to the organization.
Fixed scope
Scope, acceptance criteria and schedule settled after discovery. Change management is defined; out-of-scope requests are assessed separately. Suited to projects where architecture and requirements are mature, and to defined migration waves.
Flexible team (time and materials)
For situations where the scope evolves and priorities are set together with the organization’s backlog. A dedicated or part-dedicated team with defined roles and capacity; sprint-based planning and transparent reporting. The certified expert pool works under this model.
Value partnership (long-term)
Continuous improvement after go-live: enterprise maintenance under SLA, regular release updates, input into backlog prioritization, knowledge transfer to the organization’s team. Output, business application and prioritization are produced together; metrics and the review cadence are defined in the contract.
Product license and adaptation
For ready-to-deploy platforms: an annual license (by role matrix or by installation), an organization-specific adaptation and integration project, support under SLA and a release commitment.
Common principles
- Intellectual property and delivery of source code to the organization are defined explicitly in the contract.
- Transparent progress reporting under every model.
- Knowledge transfer is part of every model.
Which model, when
| Situation | Recommended model |
|---|---|
| The state of the current architecture and the transformation path are unclear | Discovery and architecture assessment |
| Scope is clear, acceptance criteria can be defined | Fixed scope |
| Scope is evolving, close work with the organization’s team is needed | Flexible team |
| The platform is live; continuous improvement and operational support are needed | Value partnership |
| The need can be met with a ready-to-deploy platform | Product license and adaptation |
Technology competencies
Technology is chosen to fit the problem. The areas we work in deeply:
| Area | Competency |
|---|---|
| Architecture | Event-driven microservices, CQRS, API gateway, multi-tenant platforms, domain-driven design |
| Cloud and infrastructure | Cloud-native deployment, container orchestration, infrastructure as code (IaC), multi-region high availability |
| Data | Columnar analytical databases, real-time stream processing, data warehousing and BI, data governance |
| Observability | Open telemetry standards, distributed tracing, log/metric/trace correlation, SLO-based alerting |
| Integration | Enterprise integration hub, visual flow design, versioning, real-time error tracking; integration with ERP, core banking and document management systems |
| Digital channels | Native mobile (iOS/Android), SDKs and component libraries, orchestration middleware, web banking |
| Payments and finance | Payment gateway, wallet core, multi-currency account structures, QR/instant transfer, fraud monitoring, reconciliation engines |
| Process and governance | Business process automation platforms (certified consultants), GRC, approval flows, e-signature/OCR integration |
| Quality | Test automation strategy, test data automation, UAT management, performance and load testing |
| Artificial intelligence | AI-ready data architecture, forecasting and optimization models, generative and agentic AI integration, image processing |
Let’s talk about an architecture assessment.
The discovery phase starts with a defined duration and output; the report belongs to the organization regardless of any decision to continue.