# สถาปัตยกรรม Proximity Dating / Matching App (แนว OMI) > Stack: **Android Native (Kotlin/Java) + Go (Fiber) + Next.js + PostgreSQL/PostGIS** > หลักการ: ทุกอย่างต้องรันบนบริการฟรี / self-host ได้ทั้งหมด และ "ดันงานหนักไปที่เครื่องลูกข่าย" ให้มากที่สุด --- ## 1. หลักการออกแบบ (Design Principles) | หลักการ | ความหมายเชิงปฏิบัติ | |---|---| | **Device-heavy, Server-light** | เข้ารหัส/ย่อรูป, กรอง NSFW เบื้องต้น, จัดอันดับ deck รอบสุดท้าย, เก็บประวัติแชท ทำบนเครื่องหมด → ลดค่า CPU/Storage/Bandwidth ฝั่ง server | | **Local-first** | Room (SQLite) เป็น source of truth ของ UI, server เป็นแค่ sync layer + retention สั้น | | **Privacy by default** | ไม่เคยส่งพิกัดจริงของคนอื่นออกจาก server ส่งเป็น "ระยะทางแบบ bucket" เท่านั้น | | **Stateless services + 1 stateful DB** | Go service ทุกตัว scale แนวนอนได้, state อยู่ที่ Postgres + Valkey | | **No vendor lock-in** | ทุก component มีตัวแทนแบบ open-source ที่ self-host บน VPS ตัวเดียวได้ | | **Native 100%** | ไม่มี WebView, ไม่มี cross-platform runtime → ใช้ sensor/hardware ได้เต็มและกินแบตต่ำ | --- ## 2. สถาปัตยกรรมภาพใหญ่ ```mermaid flowchart TB subgraph Client["Client Layer"] AND["Android Native App
Kotlin + Compose + Room"] WEB["Next.js Web
Landing / Admin / Moderation"] end subgraph Edge["Edge Layer"] CF["Cloudflare Free
DNS + CDN + WAF"] CADDY["Caddy / Traefik
TLS + Reverse Proxy"] end subgraph API["Go API Layer"] GW["API Gateway / BFF
REST + JWT verify + Rate limit"] WS["Realtime Gateway
WebSocket Hub"] end subgraph SVC["Go Domain Services"] AUTH["Auth Service"] PROF["Profile Service"] GEO["Geo / Discovery Service"] MATCH["Match Service"] CHAT["Chat Service"] MEDIA["Media Service"] MOD["Moderation Service"] NOTI["Notification Service"] end subgraph Data["Data Layer"] PG[("PostgreSQL 16
+ PostGIS")] VK[("Valkey / Redis
Cache + PubSub + Deck")] S3[("MinIO / R2
Object Storage")] end subgraph Ext["External Free Services"] FCM["Firebase Cloud Messaging"] TURN["Coturn
self-hosted STUN/TURN"] SMTP["Brevo Free SMTP"] end AND --> CF WEB --> CF CF --> CADDY CADDY --> GW CADDY --> WS GW --> AUTH GW --> PROF GW --> GEO GW --> MATCH GW --> MEDIA GW --> MOD WS --> CHAT AUTH --> PG PROF --> PG GEO --> PG GEO --> VK MATCH --> PG MATCH --> VK CHAT --> PG CHAT --> VK MEDIA --> S3 MEDIA --> PG MOD --> PG MOD --> S3 MATCH --> NOTI CHAT --> NOTI NOTI --> FCM AUTH --> SMTP AND -.WebRTC P2P.-> TURN ``` **จุดสำคัญ:** ลูกศรเส้นประคือ traffic ที่ **ไม่ผ่าน server** (P2P) — ตรงนี้คือหัวใจของการทำให้ "ฟรี" คือ voice/video call วิ่ง peer-to-peer, server ทำหน้าที่แค่ signaling ผ่าน WebSocket ที่มีอยู่แล้ว --- ## 3. องค์ประกอบแต่ละส่วน ### 3.1 Android Native App ```mermaid flowchart TB subgraph UI["Presentation"] CMP["Jetpack Compose Screens"] VM["ViewModel + StateFlow"] end subgraph DOM["Domain"] UC["UseCases"] MDL["Domain Models"] end subgraph DATA["Data"] REPO["Repository"] ROOM[("Room DB
profiles, deck, messages, outbox")] RETRO["Retrofit + OkHttp"] WSC["OkHttp WebSocket Client"] DS["DataStore
settings, tokens"] end subgraph PLAT["Platform Layer"] LOC["FusedLocationProvider"] CAM["CameraX + ML Kit"] WM["WorkManager"] FCMC["FCM Receiver"] BLE["BLE / Wi-Fi Aware"] TFL["TFLite On-device Model"] end CMP --> VM --> UC --> REPO REPO --> ROOM REPO --> RETRO REPO --> WSC REPO --> DS UC --> LOC UC --> CAM REPO --> WM FCMC --> REPO LOC --> BLE CAM --> TFL ``` **ทำไมต้อง Native 100% (จุดขายที่ต่างจาก app อื่น)** | ความสามารถโทรศัพท์ | ใช้ทำอะไรใน app | ค่าใช้จ่าย | |---|---|---| | `FusedLocationProviderClient` + `ActivityRecognition` | ปรับความถี่ update พิกัดตามพฤติกรรม (นั่งนิ่ง = 30 นาที/ครั้ง, กำลังเดิน = 3 นาที/ครั้ง) → ประหยัดแบตและลด write ลง DB มหาศาล | ฟรี | | **BLE Advertise/Scan + Wi-Fi Aware (NAN)** | ตรวจจับ "คนที่อยู่ในรัศมี 10-50 เมตรจริง ๆ ตอนนี้" โดยไม่ต้องยิง API เลย — feature *Crossed Paths* แบบ offline | ฟรี 100% ไม่กิน server | | `CameraX` + **ML Kit Face Detection** | Selfie verification / liveness check (หันซ้าย-ขวา-ยิ้ม) ตรวจบนเครื่อง | ฟรี on-device | | **TFLite NSFW model** (~2MB) | กรองรูปโป๊ตั้งแต่ก่อนอัปโหลด ประหยัด bandwidth + storage + ค่า moderation | ฟรี on-device | | `WorkManager` + `Constraints` | อัปโหลดรูป/sync แชท เฉพาะตอนต่อ Wi-Fi และแบตพอ | ฟรี | | **Play Integrity API** | กัน bot / emulator / app โคลน — ทดแทนระบบ anti-fraud ที่ปกติต้องจ่ายเงิน | ฟรีตาม quota | | `BiometricPrompt` | ล็อกห้องแชทด้วยลายนิ้วมือ | ฟรี | | **Notification Bubbles + Direct Share** | แชทลอยแบบ Messenger ได้โดยไม่ต้องทำ overlay เอง | ฟรี | | `Media3 + Opus encoder` | Voice note บีบอัดเหลือ ~8 kbps → ไฟล์ 1 นาทีแค่ 60KB | ฟรี | | **WebRTC (libwebrtc native)** | โทรเสียง/วิดีโอ P2P ไม่กิน bandwidth server | ค่า TURN เฉพาะเคส NAT ปิด (~10-15%) | ### 3.2 Go Backend | Service | หน้าที่ | Endpoint หลัก | |---|---|---| | **Gateway/BFF** | JWT verify, rate limit, request aggregation, response shaping ให้ Android ยิงครั้งเดียวจบหน้าจอ | `/v1/*` | | **Auth** | สมัคร/ล็อกอิน, refresh token rotation, device binding, Play Integrity verify | `/v1/auth/*` | | **Profile** | โปรไฟล์, preference, interest tag, ความสมบูรณ์โปรไฟล์ | `/v1/me`, `/v1/users/:id` | | **Geo/Discovery** | รับ location update, สร้าง candidate deck, คำนวณ score | `/v1/location`, `/v1/deck` | | **Match** | บันทึก swipe (idempotent), ตรวจ reciprocity, สร้าง match | `/v1/swipe`, `/v1/matches` | | **Chat** | WebSocket hub, persist message, sequence, receipt, sync delta | `wss://.../v1/ws`, `/v1/conversations/*` | | **Media** | ออก presigned URL, transcode/thumbnail, ผูกรูปกับ profile | `/v1/media/presign` | | **Moderation** | report queue, auto-flag, shadow ban, appeal | `/v1/report`, admin API | | **Notification** | fan-out FCM, จัดการ token, quiet hours, dedup | internal | > เริ่มจาก **Modular Monolith**: binary เดียวชื่อ `omi-api` แยกเป็น package/domain ชัดเจน แต่ deploy ตัวเดียว → แยกออกเป็น service ทีหลังเมื่อจำเป็นจริง (ประหยัด RAM บน VPS ตัวเดียว) ### 3.3 Next.js - **Landing / SEO / Deep link fallback** (SSG) - **Admin Console**: dashboard ผู้ใช้, ban/unban, ดู metric - **Moderation Console**: คิวรายงาน, ดูรูปที่ถูก flag, ตัดสิน - **Legal**: นโยบายความเป็นส่วนตัว, คำขอลบข้อมูลตาม PDPA - ใช้ Next.js เรียก Go API ผ่าน server-side (ไม่เปิด admin API ออก public) --- ## 4. Data Model ```mermaid erDiagram USERS ||--|| PROFILES : has USERS ||--|| PREFERENCES : has USERS ||--o{ PHOTOS : uploads USERS ||--|| USER_LOCATIONS : reports USERS ||--o{ DEVICES : owns USERS ||--o{ SWIPES : performs USERS ||--o{ BLOCKS : creates USERS ||--o{ REPORTS : files MATCHES ||--|| CONVERSATIONS : opens CONVERSATIONS ||--o{ MESSAGES : contains CONVERSATIONS ||--o{ RECEIPTS : tracks USERS { uuid id PK text auth_provider text auth_subject text status timestamptz created_at timestamptz banned_at } PROFILES { uuid user_id PK text display_name date birthdate text gender text bio text[] interests smallint completeness timestamptz verified_at timestamptz last_active_at } PREFERENCES { uuid user_id PK text[] want_gender smallint age_min smallint age_max int max_distance_km bool is_discoverable } PHOTOS { uuid id PK uuid user_id FK text object_key smallint order_no real nsfw_score text status } USER_LOCATIONS { uuid user_id PK geography geo char geohash5 smallint accuracy_m timestamptz updated_at } SWIPES { uuid actor_id PK uuid target_id PK text action timestamptz created_at } MATCHES { uuid id PK uuid user_a FK uuid user_b FK text status timestamptz created_at } CONVERSATIONS { uuid id PK uuid match_id FK bigint last_seq timestamptz last_message_at } MESSAGES { bigint id PK uuid conversation_id FK uuid sender_id FK bigint seq text type text body timestamptz created_at } RECEIPTS { uuid conversation_id PK uuid user_id PK bigint last_delivered_seq bigint last_read_seq } ``` **ข้อกำหนดสำคัญของ schema** - `MATCHES` บังคับ `user_a < user_b` + `UNIQUE(user_a, user_b)` → กัน match ซ้ำโดยไม่ต้อง lock - `SWIPES` PK คือ `(actor_id, target_id)` → swipe ซ้ำกลายเป็น no-op อัตโนมัติ (idempotent) - `MESSAGES.seq` เป็นเลขเรียงต่อ conversation ไม่ใช่ global → ใช้ sync แบบ `since_seq` ได้ - `MESSAGES` ทำ **partition by RANGE(created_at)** รายเดือน → ลบ partition เก่าทิ้งได้ในคำสั่งเดียว (retention 90 วันบน server, เครื่องลูกข่ายเก็บถาวรเอง) - `USER_LOCATIONS` มีแถวเดียวต่อ user (UPSERT) → ตารางเล็กเสมอ, index GiST บน `geo` ```sql -- Core geo index CREATE INDEX idx_loc_geo ON user_locations USING GIST (geo); CREATE INDEX idx_loc_fresh ON user_locations (updated_at DESC); -- Partial index for active discoverable users only CREATE INDEX idx_prof_active ON profiles (last_active_at DESC) WHERE last_active_at > now() - interval '30 days'; ``` --- ## 5. Geo & Discovery Engine ### 5.1 Flow การอัปเดตพิกัด ```mermaid sequenceDiagram participant S as Sensors participant A as Android App participant G as Geo Service participant P as PostGIS participant V as Valkey S->>A: Activity Recognition = STILL / WALKING / IN_VEHICLE A->>A: ปรับ interval ตามสถานะ Note over A: STILL = 30 min
WALKING = 3 min
VEHICLE = 1 min A->>A: ถ้าขยับ < 200 m จากครั้งก่อน ให้ข้าม A->>G: POST /v1/location {lat, lng, accuracy} G->>G: Snap to 100m grid เพื่อความเป็นส่วนตัว G->>P: UPSERT user_locations G->>V: DEL deck:{user_id} G-->>A: 204 No Content ``` **หัวใจการประหยัด:** client filter ก่อน (ขยับน้อยกว่า 200 ม. ไม่ต้องยิง) ทำให้ request ลดลง 80-90% เทียบกับการยิงตาม timer ตรง ๆ ### 5.2 Flow การสร้าง Deck ```mermaid sequenceDiagram participant A as Android App participant D as Discovery Service participant V as Valkey participant P as PostGIS A->>D: GET /v1/deck?cursor= D->>V: GET deck:{user_id} alt Cache hit และเหลือ > 10 ใบ V-->>D: candidate list else Cache miss หรือใกล้หมด D->>P: Candidate query Note over P: ST_DWithin ในรัศมี
+ filter gender/age
+ NOT EXISTS swipes
+ NOT EXISTS blocks
+ active ภายใน 7 วัน P-->>D: 200 rows ดิบ D->>D: Scoring และเรียงอันดับ D->>V: SETEX deck:{user_id} 900s end D-->>A: 20 profiles + distance bucket A->>A: Prefetch รูปด้วย Coil ล่วงหน้า 5 ใบ A->>A: เก็บลง Room เพื่อใช้ตอน offline ``` **Query แกนหลัก** ```sql SELECT p.user_id, ST_Distance(l.geo, $1::geography) AS dist_m FROM user_locations l JOIN profiles p ON p.user_id = l.user_id JOIN preferences pr ON pr.user_id = l.user_id WHERE ST_DWithin(l.geo, $1::geography, $2) -- ใช้ GiST index AND p.gender = ANY($3) AND p.birthdate BETWEEN $4 AND $5 AND pr.is_discoverable AND p.last_active_at > now() - interval '7 days' AND NOT EXISTS (SELECT 1 FROM swipes s WHERE s.actor_id = $6 AND s.target_id = p.user_id) AND NOT EXISTS (SELECT 1 FROM blocks b WHERE (b.blocker_id = $6 AND b.blocked_id = p.user_id) OR (b.blocker_id = p.user_id AND b.blocked_id = $6)) ORDER BY l.geo <-> $1::geography -- KNN operator ใช้ index ได้ LIMIT 200; ``` ### 5.3 สูตรจัดอันดับ ``` score = 0.30 * proximity_score -- ยิ่งใกล้ยิ่งสูง (แบบ log ไม่ใช่ linear) + 0.25 * activity_score -- last_active_at ล่าสุด + 0.15 * completeness_score -- โปรไฟล์ครบ + verified + 0.15 * reciprocity_score -- อัตราที่คนคนนี้ปัดขวาให้คนแบบเรา + 0.10 * interest_overlap -- จำนวน tag ที่ตรงกัน - 0.05 * exposure_penalty -- ถูกโชว์บ่อยเกินไปในรอบ 24 ชม. ``` - `exposure_penalty` สำคัญมาก เพราะกัน "โปรไฟล์ยอดนิยมกินรวบ" ทำให้ผู้ใช้ใหม่ได้ match บ้าง → คนไม่เลิกใช้ - คำนวณใน Go ล้วน ไม่ต้องมี ML service (ประหยัด) - **การจัดอันดับรอบสุดท้าย 20 ใบ ทำบนเครื่อง** ตาม interest ที่เก็บใน Room → personalization ฟรี --- ## 6. Matching Flow ```mermaid sequenceDiagram participant A as User A (App) participant M as Match Service participant P as PostgreSQL participant N as Notification participant W as WS Hub participant B as User B (App) A->>A: ปัดขวา -> เขียนลง Room outbox ทันที A->>A: UI แสดงใบถัดไปทันที (optimistic) A->>M: POST /v1/swipe {target_id, action, idem_key} M->>P: BEGIN M->>P: INSERT INTO swipes ON CONFLICT DO NOTHING M->>P: SELECT จาก swipes ว่า B เคยปัดขวาให้ A หรือยัง alt B เคยปัดขวาไว้แล้ว M->>P: INSERT INTO matches (user_a, user_b) M->>P: INSERT INTO conversations (match_id) M->>P: COMMIT M-->>A: 201 {matched: true, conversation_id} M->>W: publish match.new ไปทั้งสองฝั่ง W-->>B: match.new (ถ้า online) M->>N: enqueue push N-->>B: FCM "คุณมี match ใหม่" (ถ้า offline) A->>A: แสดงหน้า It's a Match else ยังไม่มีการปัดขวาจากอีกฝั่ง M->>P: COMMIT M-->>A: 200 {matched: false} end ``` **ประเด็นทางเทคนิค** - `idem_key` จาก client ป้องกัน double-submit ตอนเน็ตกระตุก - ถ้า request หลุด → outbox ใน Room จะ retry ผ่าน WorkManager - Race condition ที่ทั้งคู่ปัดขวาพร้อมกัน: แก้ด้วย `UNIQUE(user_a, user_b)` + `ON CONFLICT DO NOTHING` แล้ว SELECT กลับ → ได้ match เดียวเสมอ - Undo/Rewind: ลบแถว swipe ล่าสุดภายใน 10 วินาที (ให้ฟรีไปเลย ต่างจาก app อื่นที่ขายเป็น feature) ### สถานะของความสัมพันธ์ ```mermaid stateDiagram-v2 [*] --> Candidate Candidate --> Liked : ปัดขวา Candidate --> Passed : ปัดซ้าย Passed --> [*] Liked --> Matched : อีกฝั่งปัดขวา Liked --> Expired : ไม่ตอบใน 30 วัน Matched --> Chatting : ส่งข้อความแรก Matched --> Ghosted : เงียบเกิน 7 วัน Chatting --> Unmatched : ฝ่ายใดฝ่ายหนึ่งกดยกเลิก Chatting --> Blocked : กดบล็อก Ghosted --> Chatting : กลับมาคุย Ghosted --> Unmatched : ระบบเก็บกวาดอัตโนมัติ Unmatched --> [*] Blocked --> [*] Expired --> [*] ``` --- ## 7. ระบบแชท (Realtime) ### 7.1 สถาปัตยกรรม Hub ```mermaid flowchart LR A1["App A"] -->|WSS| H1["WS Hub #1"] A2["App B"] -->|WSS| H2["WS Hub #2"] H1 --> VK[("Valkey Pub/Sub
channel: conv:{id}")] H2 --> VK VK --> H1 VK --> H2 H1 --> CS["Chat Service"] H2 --> CS CS --> PG[("PostgreSQL")] CS --> NQ["Notify Queue"] NQ --> FCM["FCM"] ``` **Hub จำ connection ไว้ใน memory** (`map[userID][]*Conn`) เมื่อ instance เยอะขึ้นจึงต้องมี Valkey Pub/Sub เป็นตัวกระจาย — ตอน MVP instance เดียวข้ามส่วนนี้ไปได้เลย ### 7.2 Protocol (JSON over WebSocket) | Direction | Type | Payload | |---|---|---| | C→S | `auth` | `{token}` | | C→S | `msg.send` | `{conv_id, client_msg_id, type, body}` | | C→S | `typing` | `{conv_id, is_typing}` | | C→S | `read` | `{conv_id, up_to_seq}` | | C→S | `ping` | heartbeat ทุก 30 วิ | | S→C | `msg.ack` | `{client_msg_id, server_id, seq, ts}` | | S→C | `msg.new` | `{conv_id, seq, sender, body, ts}` | | S→C | `receipt` | `{conv_id, user_id, delivered_seq, read_seq}` | | S→C | `match.new` | `{conversation_id, profile}` | | S→C | `presence` | `{user_id, online, last_seen}` | ### 7.3 Flow ส่งข้อความ ```mermaid sequenceDiagram participant A as App A participant W as WS Hub participant C as Chat Service participant P as PostgreSQL participant N as Notification participant B as App B A->>A: บันทึกลง Room status=PENDING พร้อม client_msg_id A->>A: แสดงข้อความในแชททันที A->>W: msg.send W->>C: forward C->>P: INSERT message พร้อม seq = last_seq + 1 ในทรานแซกชัน P-->>C: server_id, seq C-->>W: ack W-->>A: msg.ack -> Room status=SENT alt B ออนไลน์ C->>W: publish conv:{id} W-->>B: msg.new B->>W: receipt delivered W-->>A: receipt -> status=DELIVERED B->>B: ผู้ใช้เปิดอ่าน B->>W: read up_to_seq W-->>A: receipt -> status=READ else B ออฟไลน์ C->>N: enqueue push N->>N: รวมข้อความหลายอันเป็น 1 notification N-->>B: FCM data message B->>B: เปิด app -> เรียก sync B->>C: GET /v1/sync?conv_id&since_seq C-->>B: ข้อความที่ขาดหาย end ``` ### 7.4 Offline Sync ``` GET /v1/sync?since= → { conversations: [{id, last_seq, unread}], messages: [...], // เฉพาะที่ seq > local_seq ของแต่ละห้อง matches: [...], next_cursor: "..." } ``` - Client เก็บ `last_seq` ต่อห้องใน Room - ถ้าห่างเกิน 500 ข้อความ → server ตอบ `truncated: true` แล้วให้โหลดแบบ paginate - **Retention ฝั่ง server 90 วัน** แต่เครื่องลูกข่ายเก็บถาวร → ต้นทุน storage คงที่ ไม่โตตามอายุ app ### 7.5 คุณสมบัติที่ให้ฟรี (ต่างจากคู่แข่ง) - ส่งรูป/voice note ไม่จำกัด (บีบอัดบนเครื่องก่อน) - โทรเสียง/วิดีโอ P2P ผ่าน WebRTC — signaling ใช้ WS ที่มีอยู่ - แปลข้อความด้วย **ML Kit Translation on-device** (โหลดโมเดลครั้งเดียว ใช้ฟรีตลอด ไม่ต้องยิง API แปลภาษา) - ค้นหาข้อความย้อนหลังด้วย **SQLite FTS5 บนเครื่อง** — เร็วกว่า server และไม่กินทรัพยากรเลย --- ## 8. Media & Moderation Pipeline ```mermaid flowchart TB START["ผู้ใช้เลือกรูป"] --> ONDEV["ตรวจบนเครื่อง"] ONDEV --> FACE{"ML Kit
เจอใบหน้า?"} FACE -->|ไม่เจอ| REJ1["เตือน: รูปโปรไฟล์ต้องเห็นหน้า"] FACE -->|เจอ| NSFW{"TFLite NSFW
score > 0.7?"} NSFW -->|ใช่| REJ2["ปฏิเสธบนเครื่อง
ไม่อัปโหลดเลย"] NSFW -->|ไม่| RESIZE["ย่อเป็น 1080px
แปลงเป็น WebP q80"] RESIZE --> PRESIGN["ขอ presigned URL"] PRESIGN --> UPLOAD["อัปโหลดตรงเข้า Object Storage"] UPLOAD --> NOTIFYAPI["แจ้ง Media Service"] NOTIFYAPI --> SERVERSCAN["สแกนซ้ำฝั่ง server
แบบ async"] SERVERSCAN --> HASH["pHash เทียบรูปที่เคยถูกแบน"] HASH --> DECIDE{"ผลตรวจ"} DECIDE -->|ผ่าน| LIVE["สถานะ APPROVED"] DECIDE -->|น่าสงสัย| QUEUE["เข้าคิวให้คนตรวจ
ใน Next.js Console"] DECIDE -->|ไม่ผ่าน| BAN["ลบรูป + บันทึก strike"] QUEUE --> HUMAN["ผู้ดูแลตัดสิน"] HUMAN --> LIVE HUMAN --> BAN REPORT["ผู้ใช้กดรายงาน"] --> QUEUE BAN --> STRIKE{"strike >= 3?"} STRIKE -->|ใช่| SUSPEND["ระงับบัญชี"] STRIKE -->|ไม่| WARN["แจ้งเตือนผู้ใช้"] ``` **อัปโหลดตรงเข้า Object Storage ด้วย presigned URL** — ไฟล์ไม่วิ่งผ่าน Go server เลย ประหยัด bandwidth และ RAM --- ## 9. Security & Privacy ### 9.1 การป้องกันพิกัด ```mermaid flowchart LR REAL["พิกัดจริง
13.7563, 100.5018"] --> SNAP["Snap เข้ากริด 100 เมตร"] SNAP --> STORE[("เก็บใน DB
server เท่านั้นที่เห็น")] STORE --> CALC["คำนวณระยะทาง"] CALC --> BUCKET["แปลงเป็น bucket"] BUCKET --> OUT["ส่งให้ client:
ห่างประมาณ 2 กม."] STORE -.ห้ามส่งออก.-x CLIENT["Client"] ``` - ระยะทางต้อง **bucket** เสมอ: `< 1 km`, `1-2 km`, `2-5 km`, `5-10 km`, `> 10 km` - ถ้าส่งเป็นตัวเลขละเอียด attacker ทำ **trilateration** ย้อนหาบ้านได้ (ช่องโหว่ที่ app ดังหลายตัวเคยโดน) - มีโหมด "ซ่อนระยะทาง" และ "หยุดแชร์ตำแหน่ง" ให้เลือก ### 9.2 Layer ความปลอดภัยอื่น | ชั้น | มาตรการ | |---|---| | Auth | Access token 15 นาที + Refresh token rotation + ผูกกับ device_id | | API | Rate limit ต่อ user และต่อ IP (token bucket ใน Valkey), body size limit | | Anti-bot | Play Integrity verdict ตอนสมัคร + ตอนทำ action สำคัญ | | Data | รูปเข้าถึงผ่าน presigned URL อายุ 5 นาทีเท่านั้น ไม่มี public bucket | | PII | เข้ารหัสระดับคอลัมน์สำหรับเบอร์/อีเมล (AES-256-GCM) | | Transport | TLS 1.3 + Certificate Pinning ฝั่ง Android | | Abuse | บล็อกเป็นแบบสองทาง (บล็อกแล้วหายจาก deck ทั้งคู่ทันที) | ### 9.3 PDPA (ประเทศไทย) - ยืนยันอายุ 18+ ตอนสมัคร (บันทึกหลักฐาน consent) - หน้าจอ "ดาวน์โหลดข้อมูลของฉัน" → export JSON ทั้งหมด - "ลบบัญชี" = soft delete 30 วัน แล้ว hard delete จริง (รวมรูปใน object storage) - Data retention policy เขียนไว้ชัดและทำจริงด้วย cron --- ## 10. Deployment & ต้นทุน ```mermaid flowchart TB subgraph VPS["Hetzner VPS - Docker Compose"] CADDY["Caddy
TLS อัตโนมัติ"] API["omi-api
Go binary"] WS["omi-ws
Go binary"] WRK["omi-worker
cron + queue"] PG[("PostgreSQL + PostGIS")] VK[("Valkey")] MIN[("MinIO")] TURN["Coturn"] MON["Prometheus + Grafana + Loki"] end subgraph FREE["Free External"] CFDNS["Cloudflare DNS/CDN"] R2["Cloudflare R2 10GB ฟรี"] FCM2["FCM ไม่จำกัด"] GH["GitHub Actions CI"] end CFDNS --> CADDY CADDY --> API CADDY --> WS API --> PG API --> VK API --> MIN WS --> VK WRK --> PG MIN -.mirror.-> R2 API --> FCM2 GH -.deploy.-> VPS ``` | รายการ | ทางเลือกฟรี | ข้อจำกัดที่ต้องรู้ | |---|---|---| | Compute | VPS ที่มีอยู่แล้ว | Go + Docker ใช้ RAM รวมประมาณ 1.5 GB | | Database | PostgreSQL self-host | ต้องตั้ง `pg_dump` + ส่งไป R2 ทุกคืน | | Object Storage | MinIO + mirror ไป R2 free 10GB | ควรเก็บเฉพาะ WebP ที่ย่อแล้ว | | CDN | Cloudflare Free | ผ่าน proxy ได้เฉพาะ HTTP/HTTPS, WebSocket ผ่านได้ | | Push | FCM | ฟรีไม่จำกัด | | SMS OTP | **ไม่ใช้** | SMS ไม่มีของฟรี → ใช้ Google Sign-In / LINE Login / Email magic link แทน | | Email | Brevo 300 ฉบับ/วัน | ใช้เฉพาะ magic link และแจ้งเตือนสำคัญ | | TURN | Coturn self-host | กิน bandwidth เฉพาะเคส NAT ปิด ควรจำกัด bitrate | | Monitoring | Grafana + Prometheus + Loki | Loki ต้องตั้ง retention 7 วัน ไม่งั้นดิสก์เต็ม | | Error tracking | GlitchTip (เบากว่า Sentry) | RAM ประมาณ 300 MB | | CI/CD | GitHub Actions | 2,000 นาที/เดือน เพียงพอ | **ประเด็นที่ต้องระวังเรื่อง "ฟรี":** ตัวที่จะแตกก่อนเสมอคือ **object storage** และ **egress bandwidth ของรูป** — จึงต้องบังคับย่อรูปบนเครื่องและใช้ CDN cache ให้หนัก --- ## 11. Observability | ประเภท | เครื่องมือ | Metric สำคัญ | |---|---|---| | Metrics | Prometheus + Grafana | `deck_generation_ms`, `swipe_qps`, `ws_active_connections`, `match_rate`, `msg_delivery_p99` | | Logs | Loki + promtail | structured JSON, มี `trace_id` และ `user_id` (hash) | | Traces | OpenTelemetry → Tempo (เปิดตอนต้องดีบักเท่านั้น) | เส้นทาง deck และ swipe | | Product | Umami self-host | funnel: ติดตั้ง → สมัคร → โปรไฟล์ครบ → swipe แรก → match แรก → ข้อความแรก | | Alert | Alertmanager → LINE Notify / Telegram | DB connection pool เต็ม, disk > 80%, WS drop rate สูง | **North star metric ของ app ประเภทนี้คือ "จำนวนบทสนทนาที่มีข้อความตอบกลับ ≥ 3 ครั้ง ต่อผู้ใช้ต่อสัปดาห์"** ไม่ใช่จำนวน match --- ## 12. Roadmap ```mermaid flowchart LR P1["Phase 1 - MVP
6-8 สัปดาห์"] --> P2["Phase 2 - Retention
4-6 สัปดาห์"] P2 --> P3["Phase 3 - Differentiate
6-8 สัปดาห์"] P3 --> P4["Phase 4 - Scale"] ``` | Phase | ขอบเขต | |---|---| | **1 — MVP** | Google Sign-In, สร้างโปรไฟล์ + รูป, location update, deck + swipe, match, แชทข้อความ, push, report/block, admin console ขั้นต้น | | **2 — Retention** | Deck ranking จริงจัง, receipt/typing/presence, voice note, ส่งรูปในแชท, selfie verification, deep link, onboarding ที่ลื่นขึ้น | | **3 — Differentiate** | **BLE Crossed Paths**, WebRTC call, on-device translation, FTS5 search, กิจกรรม/ห้องตามความสนใจ, event ใกล้ตัว | | **4 — Scale** | แยก WS Hub ออกเป็น service, read replica, partition messages, ML ranking, region sharding | --- ## 13. ความเสี่ยงและสิ่งที่ต้องเตรียมรับมือ | ความเสี่ยง | ผลกระทบ | แนวทาง | |---|---|---| | **Cold start / ไม่มีคนในพื้นที่** | deck ว่าง ผู้ใช้เลิกใช้ทันที | เปิดตัวเจาะพื้นที่เดียวก่อน (เช่น มหาวิทยาลัยหรือย่านเดียว) ไม่ใช่ทั้งประเทศ + ขยายรัศมีอัตโนมัติเมื่อ candidate < 20 | | **Gender imbalance** | ผู้ชายเยอะเกิน ผู้หญิงถูกสแปม | จำกัดจำนวน swipe ขวาต่อวัน, บังคับ verified ก่อนทัก, ให้ฝ่ายที่ถูกทักเลือกก่อน | | **Fake profile / bot** | ความเชื่อมั่นพัง | Play Integrity + selfie verification + pHash รูปซ้ำ + จำกัด 1 บัญชีต่อ device | | **ค่า storage โตเร็ว** | เกิน free tier | บังคับ WebP, จำกัด 6 รูป/คน, ลบรูปของบัญชีที่ไม่ active เกิน 1 ปี | | **Battery drain จาก location/BLE** | โดนรีวิว 1 ดาว | Adaptive interval, BLE scan เฉพาะตอนเปิด app หรือใน foreground service ที่ผู้ใช้กดเปิดเอง | | **โดนแบนจาก Play Store** | ตายทั้งโครงการ | ทำตาม policy เรื่อง dating app เคร่งครัด: ยืนยันอายุ, มีระบบรายงาน, มีนโยบายชัด, ประกาศการใช้ background location | | **โดน DDoS / scrape โปรไฟล์** | ข้อมูลรั่ว | Cloudflare + rate limit + ไม่ส่ง field ที่ไม่จำเป็น + ตรวจจับ pattern การดึง deck ผิดปกติ | --- ## 14. สรุปสิ่งที่ทำให้ต่างจาก app อื่น 1. **BLE / Wi-Fi Aware Crossed Paths** — เจอกันจริงในระยะไม่กี่เมตร ทำงานได้แม้เน็ตไม่ดี และไม่มีต้นทุน server เลย 2. **ทุกอย่างฟรีจริง** — ไม่มี paywall สำหรับ undo, ดูว่าใครไลก์, ส่งรูป, โทร เพราะโครงสร้างต้นทุนออกแบบให้ถูกตั้งแต่แรก 3. **Local-first** — เปิด app แล้วเห็นทุกอย่างทันทีแม้ offline, ค้นหาแชทย้อนหลังเร็วระดับ ms 4. **Privacy ที่จับต้องได้** — ระยะทางเป็น bucket, พิกัด snap กริด, ลบข้อมูลได้จริง 5. **Native แท้** — APK เล็ก เปิดเร็ว กินแบตน้อย ใช้ sensor ได้เต็มรูปแบบ

SECURE_ACCESS

DOWNLOAD_LOCKED

สถาปัตยกรรม Proximity Dating / Matching App (แนว OMI)

CONFIRM_DELETE