# Achivements in Digital Bank

# Capabilities
- Gamification for clients activities
- Loyalty program

# Vision
- Increase customer engagement
- Build up expertise for future loyality program

# Assumptions
- Transaction based achievements (exception: actions with bank activities such as profile editing, contact list updates)

# Roadmap
- Achievement engine
- Achievemnts
- Extend DB
- Setup own topics
- Core bank changes
- Loyality service
- Partners integration

# Out of scope
- Issues \ errors with trophy calculation

## Kafka vs SQL

| point | SQL | Kafka Streams |
| -------- | -------- | -------- |
| easy to implement | Yes | No |
| process historical data | No | Yes |
| realtime | No | Yes |
| cost of support | Low | High |
| data to store | Small | Big |
| flexible business rules | can be hard/costly | easy |

Kafka pros:
- process historical data according to new rules.
Kafka cons:
- high cost of support, like all historiical data
SQL/Triggers pros:
- low cost of support, no additional data stored
- easy to create SQL based rules
SQL/Triggers cons:
- can be hard to implement some queries without additional indexes (which can cause perfomance issues in other parts of app)

In our case we already have Kafka where all transactional data should be stored. We stick to Kafka.

# Components
https://drive.google.com/file/d/1V2XHEE_Kbkq5MxanKg8X0yHExqgyu7oU/view?usp=sharing

# ERD

# NFRs
- functional completeness - missing achievement with phone number synching
- performance (requests processing, can we scale horizontaly, possible DB scaling problems, Kafka is ok, too much data, should be used sharding?, take into account partitions setup in Kafka - possible overhead, scaling - API gateway on frontline (ISTIO), check-in mechanics for service is alive, service instantiation & growth (client data service)), sessions (sticky sessions?, to solve - JWT & global internal storage for sessions), achievements class - complex task (transactions cases), always are constraints because of FRs
- compatibility (technological & contextual & logical) - with existing infrastructure (on-premise, with Kafka), (PCI DSS?, GDPR?), NBU regulations, with labor market (not many experts)
- usability - wasn't processed yet - error detection (feedback loop, client support?), DSS possibility to test complex cases, business negotiation about reqs, how many people got achievement (calculations), reporting to users about achievement processing, what are targeting segments?, achievements integration
- reliability - Kafka backups possibly on core bank side, backup of own internal DB, same timestamp of backups?, possible disconnect between backups within data - problem?, achievements - non-critical, loyality program - via client support, recovery through log, using Kafka stream (as primary storage)
- security - using CAP (in banking), who has access to critical data? (DevOps), can user see another user's log?, support access rights (full access, but accountability checking)?, JWT (5 min) vs sessions?, user can access any other data?, PCI DSS?, what if hacker is already on server - what to do? - secret separation, audit of tokens aquiring? password changing with interval? firewall temporary opening for server starting? Kubernetes techniques vs Vault? Kafka hacked scenario - non-authorized read? transactions history access? transaction real-time access? leak of clients personal data? logic flow changes - loyality system hacked? Kafka access & autorization actions - separation of access? if maluser is in company - firewall should cover most of the cases; DevOps case - infrastructure as a code, audit trails, intrution detection system, should be used several instruments to cover edge cases in security instruments; Devolutions Desktop Remote system; endpoint protection;
- maintainability - 24/7, what new achievements can be integrated soon? how complex is integration? legacy support? testability - easy-to-use new achievents, framework testing for achievements (simplicity of testing new rules)
- portability - moving solution to another core banking in different coutry, GDPR, additional & changed rules from National Bank, Finance Monitoring new rules (etc 3 transactions instead of 1), client adaptation to local requirements (etc Israel language), add GDPR module in our solution

# BackUp Planning
**Streaming backup**, size of data for encryption? where to store encryption key? backup storage - out of our current system & with encryption (Cloud, recovery higher, append-only-storage), asymetrical key (pair, public, private(**USB, physical**)), concern - too slow? **Vault** can keep private key (at start entering several passwords from several users). Risk factor in advance - more size, more time to make each backup.

# Async API
Transaction:
- sum
- time
- client id
- category id
- merchant id
- geolocation

# Open API

# Push messages
Service & security notifications
Security question: integration of URL inside message itself

# Synchronization
Using API on demand, we can keep on client latest state, but update it on demand.
Main question is how often user uses achievements module?

# Edge Cases
- DB down
- Network issue
- if Kafka has same protocol interaction as DB -> be sure to restart server too
- 3d party library outdated, needed shifting to another
- customer states he should own achievement, but system can't give it (investigation & tech assessment)
- customer has gold card, but there are false-positive, or false-negative

# Technical Stack
- cloud system - or existing or Azure/AWS/GC
- DB - Postgres
- Java stack (or .NET stack) - backend

# Deploy

# Microservices
- 1 achievement processor - 1 service
- 1 loyalty processor - 1 service
- N transaction processors - from Kafka stream

# Goals
- +NFRs exploration (+ testing framework, + Vault, + support, + Backup storage, + Backup getter)
- +security (where, how, code, Kafka, services interaction, passwords where to save, 3 most likely points to attack)
- +finish ERD
- +backup plan
- +async API (Kafka integration)
- +open API (mobile with backend, is cache needed)
- +push (use existing one, what data, when, visible, invisible)
- +synchronization (using API -> get data, every client gets data first to operate with)
- +edge cases (technology, not so painful)
- +technical stack
- deploy (physical perimeters, how to integrate, old & new system integrations)
- SOA (loyality application, internal and external, public & private)
- microservises (true ones, integrate with NFRs)