Open to opportunities — Backend / Platform rolesBangkok Metropolitan Area, Thailand

Backend Engineer · Financial & Enterprise Systems

Papassorn Phopong

Senior Software Developer

10+ years on backend systems where ordering, latency budgets, and reliability decide whether the business can execute—fintech lending, enterprise HR/CRM, education.

I design and operate backend systems where latency, orchestration, and reliability directly bound real-world business execution—across fintech lending, enterprise HR/CRM, and education platforms.

I work both stacks in depth: Laravel/PHP and Node.js (NestJS, Express), building microservices, clean-architecture APIs, event-driven flows, and the third-party integrations that hold them together.

System signal

  • ~450–950 req/min throughput
  • ~170–230ms p95 latency
  • 8-service modular architecture
  • Financial approval systems (high reliability)

Tech Stack

Node.js stack

Node.jsTypeScriptNestJSExpress

Service APIs and async workflows under fan-out

PHP stack

PHP (native)LaravelCodeIgniter

Regulated lending and enterprise systems

Database

MySQLPostgreSQLMongoDBMSSQL

Transactional & reporting workloads

Infrastructure

RedisDocker

Caching, pub/sub, containerized systems

Core Expertise

Production-shaped work: financial workflows, orchestration across services, and how data paths behave under real constraints.

Financial-state correctness under retries, replays, and cross-team workflow edges.

Transactional workflow backends

Focus areas

ConsistencyReliabilityTransactions

Capabilities

  • Explicit DB transactions for lending and internal writes

    Blocks half-applied balances or approval state on retries, re-runs, live lending.

  • Versioned REST contracts for risk and operations handoffs

    Staged rollbacks on contract drift; downstream not forced in lockstep.

  • One authorization model across APIs and admin

    Same policy on public routes and internal tools—no cross-channel drift.

Canonical status and interactive latency budgets across async, multi-service handoffs.

Multi-service orchestration

Focus areas

LatencyOrchestrationReliability

Capabilities

  • State transitions plus durable outbox for approvals and HR-style flows

    Duplicates or lag could not silently rewrite authoritative status.

  • Narrow interactive paths; async drain for partner and batch work

    Narrow sync path owns the latency budget; queues shed uneven load off the critical path.

  • Documented service boundaries between Node and Laravel

    Explicit deprecation windows when seams moved—no implicit cross-stack coupling.

Read paths and reporting fidelity under burst load and brittle cross-service seams.

Data path & runtime discipline

Focus areas

LatencyConsistencyObservability

Capabilities

  • Redis hot reads with explicit invalidation windows

    Stale CRM reads drove wrong actions faster than index-only fixes under concurrency.

  • Schema and indexes tuned for appraisal and enrollment bursts

    Reporting stopped pinning OLTP tables during concurrent peaks.

  • Edge checks and light tracing on cross-service handoffs

    Bad handoffs surface as explicit failures—not silent cross-system drift.

See how this maps to shipped work in the Experience timeline

Featured Projects

Production systems where constraints—latency, consistency, orchestration, reliability—shaped the design.

Featured System

Loan Management System

Problem

Production lending path (FORTH SMART CAPITAL) where money-adjacent state must stay reconcilable: staged applications, multi-party approvals, customer data, and downstream risk and document systems that all need the same auditable timeline. The hard part is not CRUD—it is making every transition explainable under load and keeping orchestration from fragmenting across services.

Solution

Staged workflows with a single writer for money-critical transitions; async only where the business allows eventual consistency.

Key decision: Chose synchronous orchestration for stages that affect credit exposure, and pushed only notification and non-critical enrichment async. The tradeoff was slightly higher API latency on those steps versus guaranteed ordering and simpler reasoning when auditing a loan file.

Impact

Because approval steps were modeled as explicit state with correlation across handoffs, operations stopped chasing spreadsheets for status; end-to-end traceability for a case improved materially (~40%), and dispute resolution time dropped because the system of record matched what risk and ops actually saw.

Throughput
Sustained intake through campaign spikes without collapsing the approval queue (batch + interactive traffic on the same path).
Latency
Interactive steps target sub-second reads on hot paths; long-running checks fan out to workers so the API surface stays bounded.
Services
Intake and decision APIs, workflow orchestration, document and risk adapters, reporting projections—each with a narrow contract to the ledger.

Tech Stack

LaravelCodeIgniterMySQLREST APIs

Integration: Core services own the loan application ledger; integrations are contract-first handoffs (idempotency keys, trace IDs) so retries do not double-post or fork state.

HR Recruitment Platform

Problem

Recruitment surface built for Ngern Tid Lor where each pipeline expects different field shapes and stage semantics. The system problem is fan-out: many small reads and writes that must not block each other, plus a need to replay hiring events when a downstream consumer misbehaves.

Solution

Async-first handoffs between services; PostgreSQL per service for isolation; replay as the operational backstop.

Key decision: Moved lifecycle side effects onto a log-backed bus instead of synchronous calls, accepting stricter idempotency and replay discipline in exchange for keeping recruiter-facing reads fast while slow third-party calls and back-office jobs caught up independently.

Impact

Moving lifecycle changes onto a log-backed bus decoupled UI-facing aggregation from slow third-party calls; recruiters saw faster list loads while back-office jobs could catch up without taking down the BFF, and support could re-drive failed events instead of patching data by hand.

Tech Stack

NestJSReactKafkaPostgreSQL

Integration: BFF composes tenant-specific views; bounded contexts persist locally and publish domain events; workers consume for search indexing, webhooks, and SLA timers.

Real-time Messaging + CRM Suite

Problem

Hybrid stack (Message Center real-time push next to the Ampol Food loyalty CRM at Kanda) where live channels sit beside CRM entities that must stay consistent for revenue teams. Tension: users want instant feedback, but the canonical customer record cannot fork between Node and PHP paths.

Solution

Read-optimized edges, write-through core, cache-aside for hot lists—explicit ownership per aggregate.

Key decision: Pinned every authoritative CRM mutation to the transactional core and limited the real-time tier to delivery and presence only, accepting extra cross-stack coordination so the canonical customer record could never fork between the Node and PHP paths.

Impact

By pinning authoritative CRM mutations to one path and using Redis-backed channels only for delivery and presence, we cut inconsistent thread-to-account states; incident volume from “wrong customer context” dropped and on-call could trust which service owned writes.

Tech Stack

LaravelNode.jsMySQLRedis

Integration: Real-time tier handles connection fan-in and ephemeral state; domain mutations flow through the transactional core so there is one reconciliation story.

Employee Evaluation System

Problem

Appraisal cycles (NocNoc) with multilingual forms, role-based visibility, and HR/manager sign-offs. Unlike high-volume recruitment events, this system optimizes for immutable audit: who saw what, who attested, and which version of a template was in force when a rating was submitted.

Solution

Cycle-scoped transactions for submissions; append-only audit for manager and employee attestations.

Key decision: Optimized for immutable audit over write throughput—versioned templates and per-cycle frozen snapshots—accepting more storage and promotion-job overhead so a rating stays tied to the exact template and approvals in force when it was submitted.

Impact

Versioned evaluation templates and frozen snapshots per cycle let HR close books without disputes reopening over which template version applied; leadership reporting pulled from the same snapshot store instead of reconciling spreadsheets after the fact.

Tech Stack

Node.jsExpressMongoDBMySQLEJSVue.js

Integration: Flexible document store for evolving form definitions; server-rendered EJS workflows with Vue.js-driven form interactions (instead of jQuery-style DOM scripts); relational reporting store fed by explicit promotion jobs so analytics never reads half-written cycle data.

System Architecture

System patterns I repeatedly use in production under real constraints.

Two recurring production shapes: where strict ordering and a single writer buy correctness, and where a durability boundary plus async drain buys headroom without lying to clients about what is true yet.

Grounding. The same ideas show up across regulated lending, recruitment platforms, and hybrid messaging + CRM—the diagrams are minimal; the tradeoffs below are what mattered when traffic, audits, or integrations misbehaved.

Single-writer path with bounded orchestration

Admission
Orchestration cap
Authoritative write
Durable timeline

Tap or hover to step through the path.

Pattern

Some domains cannot tolerate parallel writers or implicit ordering. This layout keeps every money- or contract-critical transition behind one orchestration cap and one transactional commit surface so downstream risk, documents, and ops all replay the same ordered facts.

Constraints

  • Strong ordering: stages advance only after the prior transition is committed and visible to the writer.
  • Latency budget: synchronous segment stays short—anything slower than the SLA is pushed out of this path or parallelized only where invariants allow.
  • Idempotency at handoffs: external calls use stable keys so retries from gateways or clients do not fork state.

Failure mode

If ordering or the single-writer boundary slips, you get divergent loan or CRM records, audit gaps, and latency spikes as teams reconcile by hand.

Used in

Lending platform (approval ledger and regulated handoffs) and CRM suite (canonical customer mutations): the strict path is the price of defensible audits and predictable peak behavior.

Async drain behind a consistency boundary

Command accept
Durability boundary
Ordered drain
Idempotent workers

Tap or hover to step through the path.

Pattern

When work is bursty or downstream dependencies are slow, the API’s job is to accept, persist intent once, and return. Consumers then drain at their own rate with explicit retry semantics so the system degrades by lagging queues—not by corrupting core state.

Constraints

  • At-least-once delivery: workers must tolerate duplicates without double side effects.
  • Back-pressure: publish rate and consumer capacity are monitored so lag does not silently exceed business tolerances.
  • Consistency boundary: the hot path only records facts the domain already accepts; projections catch up asynchronously.

Failure mode

Wrong idempotency or missing ordering keys produces duplicate hires, double notifications, or poisoned consumers that stall the whole drain.

Used in

HR recruitment platform (lifecycle events, search and webhook fan-out) and messaging-heavy CRM edges: async work carries integration load so interactive APIs stay within their latency envelope.

Experience

Stages of backend ownership—from regulated lending cores to high-integration platforms—narrated as system evolution, not task lists.

system stablep95 (representative) ~865ms

Stage 5 — Regulated lending core

FORTH SMART CAPITAL Co., Ltd.

Current role

Stage 5 — Regulated lending core

FORTH SMART CAPITAL Co., Ltd.

Senior Software Developer

ACTIVE

February 2026 — Present

Role summary

Lead backend architecture for the Loan Management System—a financial lending platform covering application processing, approval workflows, customer data, and internal service integrations—where approval latency and orchestration correctness directly bound daily operations, risk execution, and auditability.

Throughput
~450–950 req/min (internal + partner)
Latency
~170–230ms p95 (approval slice)
Services
8 bounded modules
Critical path
<410ms orchestration budget

Key responsibilities

  • Architected API-first approval orchestration with explicit state machines so loan application, approval, and customer-data flows could evolve as separate services without shared monolith coupling.
  • Defined service boundaries around transaction-safe loan lifecycle writes versus read-heavy reporting paths to keep contention off the critical path.
  • Hardened integration contracts between internal services and external risk checks so retries and partial failures degraded predictably under peak.

Key decision

Trade-off: kept the pragmatic PHP core (CodeIgniter where it already lived, Laravel for new work) for regulated velocity while isolating orchestration behind versioned REST contracts—accepting short-term dual-stack complexity to avoid a risky big-bang rewrite during live lending traffic.

Key achievements

  • Cut typical approval-path latency from ~2.5–3s toward consistent sub-1s behavior under representative peak (orchestration + fewer synchronous hops).
  • Raised workflow reliability for multi-service handoffs by driving deterministic state transitions instead of ad-hoc email/DB flags between teams.
  • Reduced operational fire drills from ambiguous loan states by making transitions explicit, traceable, and easier to replay for audits.

Tech / domain

LaravelCodeIgniterMySQLREST APIsWorkflow orchestrationTransactional integrity

Stage 4 — Internal platform scale

Digital Media Advertising Co., Ltd.

Senior Full Stack Developer

STABLE

April 2025 — January 2026

Led backend design across two client platforms: the HR Recruitment Platform for Ngern Tid Lor (NestJS microservices behind a BFF, React front end) and the Employee Evaluation System for NocNoc (Node.js/Express, multilingual flows)—both gated by bursty traffic and cross-team approvals that demanded stable queues and clear ownership boundaries.

Stage 3 — CRM, CMS, messaging

Kanda Digital Co., Ltd.

Senior Software Developer

SCALING

April 2021 — March 2025

Delivered notification, CRM, and CMS platforms on Laravel, Nova, and React.jsMessage Center (real-time push), the Ampol Food loyalty CRM, a Rangsit University LDAPS portal, and payment-integrated CMS work—as integration count and read/write skew grew, focusing on contract stability, cache correctness, and predictable latency.

Stage 2 — Secure enterprise platform

At First Byte Co., Ltd.

Mid-Level Software Developer

STABLE

April 2018 — March 2021

Built and hardened the SCB University Application—a Siam Commercial Bank corporate learning/identity platform on Laravel + MariaDB—where SSO/OAuth login, RBAC, and data-lake reporting had to stay correct under usage spikes and strict access boundaries.

Stage 1 — Enterprise CMS foundation

Computer Systems Integration Co., Ltd.

Junior Developer & Intern

STABLE

August 2015 — March 2018

Built CMS and web platforms on CodeIgniter and MySQL for TISI, Kubota, and Thammasat University (Tupoll), plus a web-based online examination system with auto-scoring—learning to prioritize schema discipline, release safety, and operational clarity before feature velocity.

Technical Skills

The concrete inventory behind the systems above — languages, runtimes, data stores, and the integration surface I work across day to day.

Languages

PHPTypeScript / JavaScriptSQLHTML5 / CSS3Bash

Backend & APIs

Laravel & NovaCodeIgniterNode.js (Express, NestJS)Versioned REST API designAuth (JWT, OAuth 2.0, RBAC)

Architecture

MicroservicesDomain-Driven DesignHexagonal (Ports & Adapters)Clean ArchitectureEvent-driven (Kafka)

Databases

MySQLMariaDBPostgreSQLMSSQLMongoDBORMs (Prisma, TypeORM, Sequelize)

Frontend & CMS

React.jsNext.jsVue.js 3TailwindStrapi (modeling, dynamic zones, REST / GraphQL)

Integrations

Payments (Omise, 2C2P, KBank, Paysolution)LINE API / LIFFSocial loginPush (Firebase, Expo)OTPSAP REST

Tooling & AI

DockerGit / Git FlowSwaggerPostmanLokiSonarQubeClaude, Cursor & Codex (custom rules / skills, subagent orchestration)

Ways of working

Agile / ScrumSprint planningCode review & security gating

Education

Bachelor of Business Administration

Business Information TechnologyRajamangala University of Technology Suvarnabhumi

GPA3.15

Contact

If the problem is where responsibility ends between services, how ordering is preserved under retries, or how much latency budget the critical path can spend—that is the right thread to pull.

I am most useful when there is a concrete path, integration, or workflow to harden: tightening handoffs, clarifying writers and readers, and making degradation observable instead of ambiguous.

What I want to work on

  • Backend or platform roles where orchestration, consistency boundaries, and failure behavior are first-class—not afterthoughts.
  • Systems under real latency and correctness pressure: regulated domains, multi-service handoffs, or high-volume paths that still need a clear audit trail.
  • Teams that value explicit tradeoffs (what stays synchronous, what drains async, where the single writer lives) over checklist-driven “scale.”

Prefer email for scope and constraints; I usually reply within a few business days. GitHub and LinkedIn are fine for context before a first message.

Get in touch