SaFi Bank Space : Transaction history manager - component description

General description

Purpose of THM is twofold:

1. listen to all topics that relate to creation and updates of all transaction types, process those events and persist everything in THM database

2. expose all transactions with different filtering options via REST API

Context

THM listens to creation and updates of all transactions in SaFi env. Most of the transactions are dispatched by TPM, where they are initiated, but THM also processes transactions dispatched by account-manager, card-transaction-processor, referral-manager.

Once consumed, all transactions are persisted in the database. Most of updates relate to status or dates of authorization/settlement, though there are special field for some transaction types that might get updated as well. Once saved, all transactions are available via REST API’s. The REST endpoints allow for different types of grouping of filtered transactions. Transactions for account, customer, whole bank.

Integrations and external communication:

• asynchronous Kafka communication:

  • listeners self documented in repository here and also in V2

  • kafka producer for snapshots can be found here

• exposed REST API - public (/open) and a2a (/admin)

  • APIs are self documented via swagger

  • secured via common authentication library that has to be used explicitly

  • most endpoints expose read operations over transaction history, with different grouping and filtering options

  • clients:

    • for the open API, it’s only FE SaFi mobile app

    • for admin API, it’s several apps, namely: statement-manager, card-manager, backoffice-manager etc.

• REST api-client adapters:

  • generated api-clients are used - they are libraries generated during build of the target apps

  • currently integrating with: customer-manager, account-manager, merchants-manager

• database connection:

  • JDBC connection to PostreSQL database

  • configured using placeholders in default datasource in application.yml

• Idempotency & retryability - THM doesn’t employ any retry mechanism and idempotency keys are ignored, since we don’t expect idempotency to be an issue. If request is processed twice, nothing problematic happens. The worst case might be a race condition.

Transaction processing

Transactions are implemented on service layer. The approach is declarative, using javax.transaction.Transactional annotation.

All write operations pass through ph.safibank.transactionhistorymanager.service.TransactionService, so that is the top level, were transactional behavior is defined. Transactional is also used in other services and is mandatory in repositry layer.

Scalability

THM should be able to run in multiple instances, as long as the database is the same for each instance. No high volume transaction processing was used for testing the performance yet. Since we expect to use one instance only, the DB would be the bottleneck.

Approach to security

THM relies on authorization library used throughout all SaFi back-end services and also Kafka ACL (managed outside THM scope).

Domain model

Source:

Current technical debt

• use internal types on service layer to allow for stable contract, independent from avro evolution

  • SM-7759 - [THM]: Change contract on service layer To Do

• no task created, since there’s no strategy decided for this, but THM should be more robust, when it comes to processing events for transaction creation or updates

  • currently, any error/exception results in transaction not being saved

  • that creates an inconsistency between TM, but also TPM (and other possible producers)

  • integrations are the highest risk in this case

  • this is problematic not only for client, when he doesn’t see tx in his mobile app, but also for statement generation

  • additionally, this creates inconsistencies also with balances, once they are added to transactions in THM

• move 'default' controller to new mapping at /open

  • SM-7760 - [THM]: Move 'default' controller to new mapping To Do