Indonesia Global Exchange & Clearing System

PT Indonesia Global operates an exchange and clearing business that answers to Indonesian financial-sector regulators, and in 2024 it needed a system of record to match: one platform that logs, tracks, and audits transactional and trading data across multiple financial platforms, in real time, in a form a regulator can rely on. I spent six months on the build as senior full-stack developer on a team of four to six, working across the Go ingestion services, the Laravel back office, and the Next.js dashboard.

The brief

The mandate was end-to-end traceability. Every transaction and trading event moving through the client's platforms had to be captured, logged, and made auditable — recorded as it happened, not summarized after the fact. The same data had to serve two audiences with different tempos: internal stakeholders running the operation minute to minute, and external regulators who arrive with questions and expect evidence.

Concretely, that meant secure APIs in front of every entry point, real-time logging mechanisms underneath them, and data-integrity protocols binding the two together. It also meant the unglamorous half of regulatory work: scheduled compliance reports, export packages formatted for submission, and retention rules enforced by the system rather than by anyone's memory.

Constraints

• Recurring reporting obligations. Compliance reports on the regulator's schedule, exports formatted for submission, and archival that satisfies retention requirements long after any one operator has moved on. A missed cycle is not a bug ticket; it is a finding.
• Real-time logging, not end-of-day reconstruction. A trail assembled in a nightly batch is a reconstruction, and a reconstruction is not evidence. Events had to be captured at the moment they occurred, across upstream platforms that were never designed to a single standard, and surfaced on live dashboards for both stakeholders and regulators.
• Data-integrity pressure from both directions. Tamper-evidence against outside attackers is table stakes; the harder requirement is evidence against privileged insiders. Access control had to be role-based and itself audited — who read what, who changed what, when. Sensitive data was protected with asymmetric (RSA) encryption and everything moved over encrypted transport.
• No maintenance windows. Clearing does not pause for releases. Configuration changes had to land without downtime, and deployments could not drop event capture while they rolled.

Approach & decisions

The system is an event pipeline with an audit spine. Platform events land in a durable ingestion tier, flow through clearing and the ledger, and every state change is appended to a compliance log that feeds both regulator-facing reporting and a live operational dashboard.

Event-driven ingestion over point-to-point integration

The first named problem: capture events from several platforms in real time without losing any and without coupling the platforms to each other. We chose an event-driven architecture on durable message queues (RabbitMQ) with eventual consistency downstream. I rejected two alternatives: scheduled polling of each platform, because every polling interval is a window of blindness and one slow upstream stalls the sweep; and distributed transactions spanning the platforms, because they tie the audit system's availability to every upstream's worst day — an audit system that goes down with the systems it audits is not worth building. An event is acknowledged only once it is durably queued and written through to the audit log, and hash verification makes a gap in the trail detectable rather than silent.

An append-only audit trail as the spine

The second problem: tamper-evidence a regulator can verify, not just a policy they have to trust. Audit records are immutable and hash-verified — a correction is a new event, never an edit, and cryptographic hashing makes alteration detectable. The rejected alternative was conventional mutable tables guarded by permissions alone: that answers the outside attacker and says nothing about the privileged insider, which is precisely the scenario examiners probe. Retention and archival run automatically against the same log.

Three runtimes, each earning its place

Go carries the ingestion and clearing hot path, where throughput and predictable latency matter most. Laravel carries the back office — role-based access control, user management, system configuration — where the problems are well-trodden and build velocity counts. Next.js (App Router) carries the dashboard: server components for fast first paint, WebSocket for live transaction monitoring. The rejected alternative was a single-stack build, operationally tempting but it would have meant either pushing clearing throughput through PHP or rebuilding solved back-office machinery in Go. The honest cost is that three runtimes are real operational surface; we paid it down with the same Clean Architecture layering in every service — handler, use case, repository — so the domain logic reads the same way in every language, and with uniform packaging underneath: Docker images, Kubernetes orchestration, Prometheus and Grafana for observability.

Releases that do not blink

With no maintenance windows available, releases run blue-green behind health checks with automated rollback, configuration changes apply without restarts, and traffic is load-balanced across instances. These are deliberately boring choices — release engineering in a clearing system is not where novelty earns its keep.

Evidence

An audit dossier should hold itself to the standard it describes, so the claims here sit at their honest rung: verifiable system facts first, design goals labeled as design goals.

What the system verifiably does:

• Real-time regulatory event logging with immutable, hash-verified audit trails
• Automated compliance reporting, with exports formatted for regulatory submission and retention enforced by the system
• Role-based access control in which access itself is written to the audit trail
• Built with Next.js, Go, and Laravel services over PostgreSQL, Redis, and RabbitMQ

What it was designed for:

• Designed for 99.9% availability — redundancy, automated failover, health-checked blue-green releases, and alerting on the signals that precede failure
• Engineered against a sub-second query budget for the live views, via indexed reads and Redis caching
• Built to satisfy Indonesian financial-sector reporting and retention requirements

One line has to be drawn plainly: compliance is a certification that auditors and regulators grant, not a claim an engineer gets to make. What I can state is what the system does in service of it — every transaction and trading event written to a tamper-evident trail, reports produced on schedule, exports ready for submission. Where this dossier is otherwise silent — client figures, named testimony — the silence is deliberate: nothing appears here without written permission.

Stack notes

Frontend: Next.js (App Router), TypeScript, and Tailwind CSS, with WebSocket-fed live views. Services: Go for ingestion and clearing, Laravel for the back office. Data: PostgreSQL as the system of record, Redis for caching, RabbitMQ as the event transport. Operations: Docker and Kubernetes, Jenkins pipelines, Prometheus and Grafana. The same handler / use case / repository layering runs through all three codebases.