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

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)

Node.js stack

Node.js • TypeScript

NestJS • Express

(Production APIs, microservices)

PHP stack

PHP (native) • Laravel

CodeIgniter

(Enterprise & financial systems)

Database

MySQL • PostgreSQL

MongoDB • MSSQL

(Transactional & reporting workloads)

Infrastructure

Redis

Docker

(Caching, pub/sub, containerized systems)

View System Work
Explore 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

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.

System snapshot

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.

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.

Result (cause → effect)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.

Tech

LaravelCodeIgniterMySQLREST APIs

Boundaries & 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.

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

HR Recruitment Platform

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.

ResultMoving 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

NestJSReactKafkaPostgreSQL

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

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

Real-time Messaging + CRM Suite

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.

ResultBy 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

LaravelNode.jsMySQLRedis

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

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

Employee Evaluation System

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.

ResultVersioned 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

Node.jsExpressMongoDBMySQLEJSVue.js

Boundaries & 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.

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

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

Stage 5 — Regulated lending core

FORTH SMART CAPITAL Co., Ltd.

Senior Software Developer

ACTIVE

February 2026 — Present

Lead backend architecture for a financial lending stack where approval latency and orchestration correctness directly bound daily operations, risk execution, and auditability across teams.

System work

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

Impact

  • —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 surface

LaravelCodeIgniterMySQLREST APIsWorkflow orchestrationTransactional integrity

Stage 4 — Internal platform scale

Digital Media Advertising Co., Ltd.

Senior Full Stack Developer

STABLE

Stage 3 — CRM, CMS, messaging

Kanda Digital Co., Ltd.

Senior Software Developer

SCALING

Stage 2 — Secure admissions

At First Byte Co., Ltd.

Mid-Level Software Developer

STABLE

Stage 1 — Enterprise CMS foundation

Computer Systems Integration Co., Ltd.

Junior Software Developer

STABLE

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.

GitHubLinkedIn