Farhan Riuzaki
IT Architect at Bank Mega
8+ years · Enterprise Banking · 1M+ daily transactions
Backend systemsthat scale.Architecture that lasts.
I build systems that handle money while everyone sleeps.
7+ years across banking core systems and IT consulting — from reconciliation engines at Bank Mega to leading an IT agency as HoD/CTO.
Selected Work
Enterprise systems I've architected and built. Each one handles real transactions, real users, real stakes.
Additional Projects
Journey
From developer to architect—each role shaped how I think about systems.
2018
Fullstack Developer
Zamasco
Shipped first high-traffic production system
2019
Senior Developer
HTC Global
Architected core reconciliation engine
2022
Tech Lead
Bank Mega
Delivered 85% perf gain via refactoring
2023
Engineering Lead
Bank Mega
Orchestrated cross-squad architecture
Now
IT Architect
Bank Mega
Designing bank-wide distributed systems
2018
Fullstack Developer
Zamasco
Shipped first high-traffic production system
2019
Senior Developer
HTC Global
Architected core reconciliation engine
2022
Tech Lead
Bank Mega
Delivered 85% perf gain via refactoring
2023
Engineering Lead
Bank Mega
Orchestrated cross-squad architecture
Now
IT Architect
Bank Mega
Designing bank-wide distributed systems
Founder + CEO
SunnyGoIT Agency · 2024–Now
HoD / CTO
PT Daffascript Naga AsiaIT Agency · 2023–Now
Convictions
What 7 years of production failures taught me.
Eventual consistency is a business decision, not a technical one
Banks don't fail because of CAP theorem. They fail because engineers made distributed systems decisions without understanding business SLAs. I've learned to ask 'what's the cost of stale data?' before drawing any architecture diagram.
The best migration is the one users never notice
Migrated 12M+ records across banking cores with zero downtime. The secret isn't fancy tooling—it's paranoid rollback planning and treating every migration like it will fail at 3AM.
Premature abstraction costs more than duplication
I've seen teams paralyzed by 'elegant' abstractions built for requirements that never came. Now I follow a rule: duplicate until you understand the pattern, abstract when you feel the pain.
Logs lie. Traces reveal. Metrics prove.
Production debugging taught me this hierarchy. Logs tell you what code thinks happened. Traces show you what actually happened. Metrics tell you if anyone cares.
The Approach
How those lessons become architecture. Every decision here has a story behind it.
Monolith until it hurts, microservices when it pays
Started 3 projects as microservices. Rewrote 2 back to monolith. Now I ask: 'Do we have the team to operate this?'
Async by default, sync when you must
Banking reconciliation runs 4x faster after moving to event-driven. Users don't wait, systems don't block.
Cache aggressively, invalidate paranoidly
A 50ms cache hit vs 800ms database query. But stale financial data? That's a compliance issue.
Defense in Depth
Stack Layers
Pattern in Practice
Config-Driven Architecture
Same principle, different domains. Matching rules in Recon. Valuation formulas in MTM. Workflow states in SFI. Access policies in API Portal. Business logic belongs in config, not code.
See projects→/*** Config-Driven Architecture* Same principle, different domains*/const configs = {// Recon Engine — Matching Rulesrecon: {keys: ['trx_date', 'amount', 'ref_no'],tolerance: { amount: 0.01, date: '1d' }},// MTM Module — Valuation Logicmtm: {method: 'FIFO',fxSource: 'reuters',precision: 8},// SFI Super App — Workflow Statessfi: {states: ['draft', 'pending', 'approved', 'done'],approvers: ['ops', 'finance']},// API Portal — Access Policiesapi: {rateLimit: 1000,roles: ['internal', 'partner']}};// Business changes config → zero deployment 🚀
Auto Reconciliation Engine
From manual spreadsheet chaos to a 5-stage pipeline that reconciles millions of financial transactions daily. Built and evolved over 7 years—from Senior Developer to IT Architect.
- —Data from 4+ sources manually copied to spreadsheets
- —No traceability—why did this match or fail?
- —Days to investigate a single mismatch
- +5-stage pipeline: Source → Staging → Config → Recon → Report
- +Every result traceable to exact input and rule
- +Explicit states: Matched, Mismatch, Exception—each actionable
Key Architectural Decisions
Staging First, Logic Later
Separating staging from reconciliation logic prevents raw data issues from corrupting results. Enables safe reprocessing without re-ingestion, and creates clear debugging boundaries.
Metadata-Driven Reconciliation
Rules and matching keys defined in database, not code. Business users modify reconciliation strategies without deployments. Different rules per data type, version-controlled through database history.
Explicit State Modeling
Matched, Mismatched, and Exception are first-class concepts—not side effects. Each state has clear actions: Matched archives, Mismatch investigates, Exception handles. Every transition recorded.
Auditability by Design
Every reconciliation outcome traces back to: source data, transformation rules, matching logic, and execution context. Built for the auditor who asks 'why did this match?' at 2AM.
Results
85%
Faster processing
60-80%
Workload reduction
100%
Audit traceable
7 years
Production proven
About
The person behind the architecture.
I design systems that survive scale, audits, and 3AM incidents.
As an IT Architect and Backend Engineer with 8+ years of experience, I bridge the gap between technical purity and business reality. My work spans banking cores, deterministic financial modules, and supply chain systems that handle millions in daily transactions.
I don't just write code; I design for failure. But beyond backend, I bring security-first thinking and an eye for UI/UX. I believe good architecture should be invisible—users shouldn't worry about the database, they just experience systems that work.
Currently exploring how RAG (Retrieval-Augmented Generation) transforms enterprise data access and applying Blockchain principles to solve distributed reconciliation. Always building, always learning.
Expertise
Currently: IT Architect at Bank Mega
Open to architecture consulting & interesting conversations
Need a backend that scales
and architecture that lasts?
Let's architect your next core system.
Or send a message