- Engagement: June 2023 - Mar 2024 (8 months)
- Team: Solution Architect, 4 .NET Developers, PL/SQL Developer(s), QA (Automation), DevOps, PM/BA
- Type / Platform: Platform (on-prem) Web API + Background Workers, Kubernetes
- Performance Targets: 300,000 transactions/day; peaks up to 450 TPS; zero-downtime releases
- Security: Encrypted in transit, OAuth2 via Keycloak, hardened service-to-service comms
- Tech Stack: .NET 6, Oracle 19, RabbitMQ, Redis, Keycloak, Kubernetes, GitLab, New Relic
One of the banks in Georgia, operating nationwide. The institution runs an Oracle-based core banking system on-premises and is modernizing toward a Kubernetes-based platform. This program begins by decoupling the “Available Balance” capability, paving the way for progressive migration of the wider CBS. (Client name withheld under NDA.)
- Monolith coupling: Balance calculations lived inside CBS (Oracle 10g/Forms), tightly coupled to CP queries and local computation
- Reliability & scale: The platform needed to meet 300k/day throughput and 450 TPS peaks with zero downtime deployments
- Operational consistency: Introduce eventual consistency for reads while ensuring reliable payment authorization and clear contracts between CBS, CP, and Payments
- Security & compliance: Encrypted transport across DB, queues, k8s; OAuth2 client-credential flows; auditable logs and rate histories
- Target architecture (on-prem k8s): Web API (.NET 6) for balance queries, aggregate balances, FX rates, and async transaction initiation. Background workers for CDC events from CBS, transaction orchestration, FX updates, and scheduled jobs (snapshots, timeouts). Oracle 19 as system of record; RabbitMQ for messaging; Redis to cache CP responses (30–50s TTL) for high-read endpoints
- Data capture & flows: CDC from CBS tables into queues; workers apply updates; OperationLog and AccountSnapshot for auditability and daily snapshots. InternalHolds model to correlate async transactions and final clearing via CBS
- API design & versioning: REST endpoints under /api/v{n}; Keycloak protection; breaking changes handled via sequential versions and staged client migration
- Resilience patterns: Retry / Dead-Letter Queue for eventually consistent processing; idempotency in workers; fail-fast message handling
- Zero-downtime delivery: Canary releases for stateless services; multi-step plan for external contract changes; orchestrated DB schema migration (Data Guard strategy) to maintain availability
- Engineering system: GitLab CI/CD, trunk/branching model, automated unit & integration tests, scheduled E2E; New Relic for logs/metrics; environment topologies for Dev/Stage/Prod.
Decoupled core capability: Balance becomes a first-class service, reducing CBS complexity and unlocking parallel modernization.
Reliable authorizations: Clear ownership of payment authorization with robust messaging and caching improves responsiveness and stability.
Operational continuity: Zero-downtime deployment practices minimize disruption and support frequent iteration.
Future product enablement: The platform lays the foundation for offerings like virtual IBANs and crypto wallets, as well as improved aggregate balance UX.
- Solution Architect
- 4 .NET Developers
- PL/SQL Developer
- QA (Automation)
- DevOps
- PM/BA