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

Backend Engineer · Financial & Enterprise Systems

Papassorn Phopong

Backend Engineer

Focused on scalable systems and API architecture

I design and operate backend systems where latency, orchestration, and reliability directly impact real-world business execution.

I focus on scalable APIs, modular service architectures, and high-performance workflows across financial and enterprise systems.

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

Production APIs, microservices

PHP stack

PHP (native)LaravelCodeIgniter

Enterprise & financial systems

Database

MySQLPostgreSQLMongoDBMSSQL

Transactional & reporting workloads

Infrastructure

RedisDocker

Caching, pub/sub, containerized systems

View System WorkExplore ArchitectureContact

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

  • 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

  • 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

  • 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.

How this maps to shipped stages — Experience timeline

Featured Projects

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

Featured System

Financial Lending Platform

Problem

Production lending path where money-adjacent state must stay reconcilable: staged applications, multi-party approvals, 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

Multi-tenant recruitment surface where each client expects different field shapes and pipeline 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.

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 where live channels (presence, threads) sit next to 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.

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 with multilingual forms, role-based visibility, and legally sensitive 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.

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

Hover to step through the path.

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.

If this is wrong: 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

Hover to step through the path.

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.

If this is wrong: 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 readout ~865ms

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 a financial lending stack where approval latency and orchestration correctness directly bound daily operations, risk execution, and auditability across teams.

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 lending, risk, and ops could evolve 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 a pragmatic PHP/Laravel core 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 for recruitment and performance systems where bursty HR traffic, multilingual flows, and cross-team approvals demanded stable queues and clear ownership boundaries.

Stage 3 — CRM, CMS, messaging

Kanda Digital Co., Ltd.

Senior Software Developer

SCALING

April 2021 — March 2025

Owned evolution of CRM, CMS, and real-time messaging backends as integration count and read/write skew grew—focusing on contract stability, cache correctness, and predictable latency under mixed workloads.

Stage 2 — Secure admissions

At First Byte Co., Ltd.

Mid-Level Software Developer

STABLE

April 2018 — March 2020

Built and hardened university admissions backends where RBAC, document workflows, and batch reporting had to stay correct under enrollment spikes and strict access boundaries.

Stage 1 — Enterprise CMS foundation

Computer Systems Integration Co., Ltd.

Junior Software Developer

STABLE

February 2016 — March 2018

Delivered CMS and internal tooling backends in active enterprise deployments—learning to prioritize schema discipline, release safety, and operational clarity before feature velocity.

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

GitHubLinkedIn