Skip to content

11.1 · Persistence topology

Inventory ของทุก datastore ที่พบใน ~25 repo — engine, owner, ใครต่อตรงบ้าง และ host ไหนถูก "แบ่งเช่า" ระหว่างหลาย service


ภาพรวม — 6 engine, อย่างน้อย 16 logical database, 1 directory service

Engineจำนวน logical DB ที่พบกลุ่มที่ใช้
MariaDB2 (vtrc, vtrc-centralize)Legacy Core
MSSQL≥ 11Legacy Core, 2way, Domain Microservices, Meeting
MongoDB2 (1 ใช้งานจริง, 1 dead)Domain Microservices (chat-center-api), 2way (2way-vtrc-api)
PostgreSQL1 (pms_ai)Domain Microservices (workflow-api)
LDAP/AD1Legacy Core (cu-central-api)
Local disk / SFTPหลายจุดกระจายทั่วแพลตฟอร์ม

ไม่มี repo ใดใช้ Redis เป็น cache จริง — vtrc-api มี Redis client ที่ config ไว้แต่เป็น vestigial (ดู Volume 3 vtrc-api/04-centralize-bridge)


MariaDB — Legacy Core เท่านั้น

DBOwnerConnection varRole
vtrcvtrc-apidbapplication state หลัก — users, sessions, roles, leave, withdraw, fund, notification, master data
vtrc-centralizevtrc-apidb2cross-schema bridge table (centralize/user) ที่ map ไปหา HRMI ผ่าน refId/EmpCode

รายละเอียด model, syncModelToTable(), connection pool sizing (100 × 2 × 4 replica) ดู Volume 3 vtrc-api/05-persistence

ไม่มี repo อื่นนอกจาก vtrc-api ต่อ MariaDB นี้ตรง — ทุก repo อื่นที่ต้องการข้อมูล vtrc/vtrc-centralize ต้องผ่าน GraphQL ของ vtrc-api ยกเว้น benefit-api และ workflow-api ที่ต่อ MSSQL schema ชื่อ vtrc ตรง (ดูหัวข้อถัดไป — คนละ physical database กับ MariaDB vtrc ของ vtrc-api, ชื่อชนกันเฉย ๆ แต่เป็นอีก schema ที่ domain microservices อ่านเขียนตรง)


MSSQL — engine ที่ใช้มากที่สุด กระจายอย่างน้อย 3 host

Host: HRMI (Chula) — เจ้าของข้อมูลบุคคลตัวจริง

DBOwner (write)Reader (cross-connect)
dbHRMI_CenterHRMI (Chula)cu-central-api (Sequelize), centralize-api (TypeORM center), workflow-api (TypeORM hrmi, read), chat-center-api (raw SQL cross-schema จาก connection center ไปหา dbHRMI_Center.dbo.temp_pee_na_table), sso-api (raw SQL cross-schema ไปหา temp_pee_na_table เดียวกัน)
dbHRMI_Center_NBCHRMI (Chula), NBC mirrorcentralize-api (TypeORM nbc), workflow-api (TypeORM hrmi_nbc, read)

VTRC ไม่เคยเขียนกลับเข้า dbHRMI_Center* — กฎเหล็กเดียวกับที่ v1 Volume 8 บันทึกไว้สำหรับ legacy 5 service ยังจริงสำหรับ 25 repo ทั้งหมด (ดู 11.2)

Host: 10.188.128.61 — domain microservices + 2way แบ่งเช่า host เดียวกัน

DBOwner (write)Cross-connect readers/writers
2way2way-api (TypeORM main)chat-center-api (TypeORM main, synchronize: true — ดู 11.2)
benefitbenefit-api (TypeORM main)workflow-api (TypeORM benefit read-only + benefit_write)
recruitmentrecruitment-api (TypeORM main)ไม่พบ cross-connect นอกจาก recruitment_ai (ดูล่าง)
recruitment_airecruitment-api (connection ai) + ai-recruitment-api (raw mssql driver, ไม่มี ORM)ทั้งสอง repo เขียน jobReqPosition คู่ขนานกับ recruitment.dbo.jobReqPosition โดยไม่มี sync mechanism ชัดเจน — ดู Volume 6 ai-recruitment-api/03-persistence
pms (ชื่อ inferred จาก cross-schema reference pms.dbo.tbnotify ที่ 2way-api cron อ้างถึง — ยังไม่ verify ตรงจาก pms-api เอง)pms-api (main connection)2way-api (NotificationPmsTaskService cross-schema query pms.dbo.tbnotify[2way].dbo.userline — ดู Volume 5 2way-api/03-persistence-integrations)
dbWorkforce (ชื่อจาก connection var workforce ของ pms-api)HR/workforce system (owner นอก repo scope ของ manual นี้)pms-api เชื่อมตรงจาก 10 module — ดู Volume 6 pms-api/03-persistence

Host นี้จึงมีอย่างน้อย 6 logical database ของ 3 กลุ่มแพลตฟอร์มต่างกัน (2way, Domain Microservices) แชร์กัน — เป็น host เดียวที่มี "ความหนาแน่นของ cross-service coupling" สูงสุดในทั้งระบบ

Host อื่น ๆ (MSSQL)

DBOwnerหมายเหตุ
vtrc_commonvtrc-common (TypeORM main)ไม่พบ cross-connect ขาออก — เป็น inbound-only service (เรียกจาก benefit-api, vtrc-web, vtrc-rc-backoffice)
DB ของ 2way-vtrc-api (ชื่อ UNVERIFIED — persistence chapter ไม่ได้ยืนยันชื่อ database ตรง ๆ)2way-vtrc-api (Sequelize)Express legacy service คนละตัวกับ 2way-api (NestJS) แม้ชื่อคล้ายกัน — ดู Volume 5 2way-vtrc-api/03-persistence-integrations
DB ของ meeting-vtrc-api (ชื่อ UNVERIFIED)meeting-vtrc-api (Sequelize, constraints: false ทุก association)ตาราง Approver, GroupMeeting, UserGroup, Meeting, login — ดู Volume 7 meeting-vtrc-api/03-persistence-integrations
DB ของ sso-api (ชื่อจาก env DB_NAME, UNVERIFIED)sso-apiตาราง SSOUsers เป็นของตัวเอง แต่ cross-schema query ไปหา dbHRMI_Center.dbo.temp_pee_na_table — ดู Volume 6 sso-api/03-persistence-integrations

MongoDB — 2 instance, สถานะต่างกันโดยสิ้นเชิง

DBOwnerสถานะ
chatDBchat-center-api (Mongoose)ใช้งานจริง — เก็บ chat room/message state
Mongo (ไม่มีชื่อยืนยัน)2way-vtrc-api (Mongoose)dead — connection ไม่ทำงาน แต่ production credentials ยังถูก commit ไว้ในซอร์ส (SEC-2WAYVTRC-03, Critical) — ดู Volume 5 2way-vtrc-api/03-persistence-integrations

PostgreSQL — 1 instance เดียวในทั้งแพลตฟอร์ม

DBOwnerหมายเหตุ
pms_aiworkflow-api (TypeORM connection postgres)เป็น engine เดียวที่ไม่ใช่ MariaDB/MSSQL ในทั้งระบบ — เชื่อมกับ AI Router ภายนอกสำหรับ LLM call ดู Volume 6 workflow-api/03-persistence-integrations

LDAP/Active Directory

ระบบOwnerRole
AD (HRMI staff directory)cu-central-apibind login ด้วย adUsername/password ผ่าน activeDirectory.connector.js, rejectUnauthorized: false (SEC-CU-06, Critical) — ดู Volume 3 cu-central-api/02-auth-ldap-directive

Local disk / SFTP / อื่น ๆ ที่ไม่ใช่ database แต่เป็น persistence จริง

ประเภทOwnerหมายเหตุ
Local disk (chat attachment)chat-center-apiไม่มี lifecycle/cleanup policy ที่ยืนยัน
Local disk (file storage)vtrc-commonใช้ร่วมกับ benefit-api ผ่าน API
Local disk (upload/webdeployment)vtrc-apiendpoint /webdeployment ไม่มี auth (SEC-VTRC-API-03, Critical)
SFTP ภายนอก (FMIS, 10.188.128.22)benefit-apiข้อมูลการเงิน/สวัสดิการส่งออกไปนอกเครือข่าย VTRC
Git repository เอง (ไม่ใช่ runtime store แต่เก็บข้อมูลถาวร)report-logrequest_*.log มี PII จริง (citizenId, birthDate, empCode) ถูก commit เข้า git — เทียบเท่า data leak ระดับ datastore (SEC-REPORTLOG-01, Critical)

Repo ที่ไม่มี server-side datastore ของตัวเอง

Repoเหตุผล
job-scheduler-apiไม่มี TypeORM config, ไม่มี entity — เป็น stateless HTTP proxy ไปหา incident-management-api
meeting-backoffice, meeting-backoffice-new, 2way-meeting-backofficepure frontend — ไม่มี database, พึ่ง backend API ล้วน
vtrc-web, vtrc-rc-backoffice, vtrc-backoffice, vtrc-backoffice-new, recruitment-webfrontend — persistence ที่มีคือ localStorage/sessionStorage ฝั่ง browser เท่านั้น (ดู Volume 12 · 01-auth-mechanisms-inventory สำหรับ token storage)
vtrc-mobile, new-vtrc-mobile, vtrc-application-frontmobile — persistence คือ AsyncStorage/device storage เท่านั้น
vtrc-ocr-apiไม่มี database จริง — mock OCR engine เก็บผลลัพธ์ใน memory เท่านั้น (QUAL-OCRAPI-02)
2way-batchไม่มี persistence chapter ยืนยัน dedicated database — ทำงานเป็น cron executor เรียก service อื่นเป็นหลัก

ภาพรวม topology แบบ ASCII

MariaDB ─────────────────────────────────────────────────────────
  vtrc               ◄── vtrc-api (owner, R/W)
  vtrc-centralize    ◄── vtrc-api (owner, R/W)  ── bridge ไป HRMI ผ่าน refId

MSSQL @ HRMI (Chula) ──────────────────────────────────────────────
  dbHRMI_Center      ◄── cu-central-api, centralize-api (owner-ish, R)
                     ◄── workflow-api (R), chat-center-api (R, cross-schema)
                     ◄── sso-api (R, cross-schema)
  dbHRMI_Center_NBC  ◄── centralize-api (R), workflow-api (R)

MSSQL @ 10.188.128.61 ─────────────────────────────────────────────
  2way               ◄── 2way-api (owner, R/W)
                     ◄── chat-center-api (R/W, synchronize:true ⚠)
  benefit            ◄── benefit-api (owner, R/W)
                     ◄── workflow-api (R via `benefit`, R/W via `benefit_write`)
  recruitment        ◄── recruitment-api (owner, R/W)
  recruitment_ai     ◄── recruitment-api (`ai` conn), ai-recruitment-api (raw driver)
                         both write jobReqPosition-* — no confirmed sync
  pms (name inferred) ◄── pms-api (owner, R/W)
                     ◄── 2way-api (R/W cross-schema, tbnotify)
  dbWorkforce        ◄── [external HR/workforce owner]
                     ◄── pms-api (R/W from 10 modules)

MSSQL (own host, unverified name) ─────────────────────────────────
  vtrc_common        ◄── vtrc-common (owner)
  2way-vtrc-api DB   ◄── 2way-vtrc-api (owner)
  meeting-vtrc DB    ◄── meeting-vtrc-api (owner)
  sso-api DB         ◄── sso-api (owner, R/W) + cross-schema R to dbHRMI_Center

MongoDB ────────────────────────────────────────────────────────────
  chatDB             ◄── chat-center-api (owner, active)
  (unnamed)          ◄── 2way-vtrc-api (owner, DEAD connection)

PostgreSQL ─────────────────────────────────────────────────────────
  pms_ai             ◄── workflow-api (owner)

LDAP/AD ─────────────────────────────────────────────────────────────
  HRMI directory     ◄── cu-central-api (bind only, rejectUnauthorized:false)

รายละเอียดของแต่ละเส้น cross-connect (ใครเรียกใคร ผ่านอะไร มีความเสี่ยงอะไร) อยู่ที่ 11.2 Cross-service coupling