Giới thiệu dự án

Sự bùng nổ của hạ tầng viễn thông và thiết bị di động tại Việt Nam đã thúc đẩy mạnh mẽ các nền tảng mạng xã hội. Theo thống kê năm 2021, Việt Nam có hơn 43,7 triệu người sử dụng điện thoại thông minh (chiếm 44,9% dân số), với thời gian trung bình dành cho mạng xã hội lên tới 4 giờ 30 phút mỗi ngày. Song song đó, theo Cục Thú y, cả nước có trên 5 triệu hộ dân nuôi chó, mèo (chiếm khoảng 58% tổng số hộ), mở ra thị trường chăm sóc thú cưng đầy tiềm năng.

Mặc dù nhu cầu kết nối lớn, cộng đồng người yêu thú cưng hiện nay chủ yếu sinh hoạt phân tán trên các hội nhóm Facebook, Instagram hay TikTok. Mô hình này bộc lộ nhiều điểm nghẽn: nội dung bị phân mảnh, thuật toán phân phối chung không tối ưu cho dữ liệu thú cưng (chủng loại, phả hệ, lịch tiêm chủng), khả năng tìm kiếm thông tin chuyên biệt kém và thiếu các tiện ích quản lý tài nguyên số (hình ảnh, video, nhật ký nuôi dạy).

+-------------------------------------------------------------------------+
|                          THỰC TRẠNG THỊ TRƯỜNG                          |
|  58% Hộ nuôi thú cưng  <--->  43.7M Smartphone  <--->  4.5h MXH/ngày    |
|                                                                         |
|                          VẤN ĐỀ CỐT LÕI                                 |
|  [Cộng đồng phân tán] -> [Dữ liệu thiếu cấu trúc] -> [Hiệu năng nghẽn]  |
+-------------------------------------------------------------------------+

Đề tài khóa luận tốt nghiệp "Xây dựng mạng xã hội cho những người yêu thú cưng (4Pet)" được thực hiện bởi sinh viên ngành Kỹ thuật Phần mềm, Trường Đại học Công nghệ Thông tin - ĐHQG-HCM, dưới sự hướng dẫn của ThS. Nguyễn Công Hoan. Dự án hướng tới giải quyết triệt để các bài toán trên thông qua việc phát triển nền tảng mạng xã hội B2C chuyên biệt, kết hợp kiến trúc kỹ thuật phân tán hiện đại.

Mục tiêu của dự án

  1. Phân tích và kiểm chứng thị trường: Xây dựng phiên bản MVP (Minimum Viable Product) theo mô hình B2C nhằm kiểm chứng hành vi người dùng và nhu cầu tương tác cộng đồng yêu thú cưng.
  2. Thiết kế trải nghiệm người dùng tối ưu: Xây dựng ứng dụng di động đa nền tảng (iOS & Android) bằng Flutter với giao diện mượt mà, đạt tốc độ khung hình chuẩn 60 FPS.
  3. Hiện thực hóa kiến trúc Microservices hiệu năng cao: Tách biệt các domain nghiệp vụ (Auth, Story, Media, Chat, Reaction, Notification) sử dụng Node.js và Kotlin.
  4. Tối ưu hóa luồng dữ liệu phân tán: Triển khai mô hình CQRS (Command Query Responsibility Segregation) kết hợp Change Data Capture (CDC) với Debezium và Apache Kafka để đồng bộ dữ liệu sang Elasticsearch theo thời gian thực.
  5. Chuẩn hóa hạ tầng vận hành Cloud-Native: Đóng gói container với Docker, tự động hóa quy trình CI/CD qua GitHub Actions và triển khai, mở rộng linh hoạt trên Kubernetes (Azure Kubernetes Service - AKS).

Phạm vi và giới hạn dự án

  • Phạm vi chức năng: Xác thực người dùng (Facebook OAuth 2.0/JWT), tương tác bảng tin (Story CRUD, đa phương tiện), hệ thống tương tác (Comment, Reaction), kết nối thời gian thực (Chat 1-1, Realtime Notification qua GraphQL Subscription), khám phá nội dung (Discover, Elasticsearch Engine), quản lý hồ sơ cá nhân và người theo dõi (Follower/Following).
  • Phạm vi địa lý & đối tượng: Tập trung người dùng nuôi và yêu thích thú cưng tại Việt Nam độ tuổi 15–40, định hướng mở rộng thị trường Đông Nam Á (Philippines) và châu Âu (Bồ Đào Nha).
  • Giới hạn kỹ thuật: Phiên bản MVP chưa tích hợp cổng thanh toán trực tiếp cho dịch vụ B2B (spa, phòng khám, mua sắm phụ kiện) và chưa hỗ trợ tính năng livestream video thời gian thực.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Thị trường ứng dụng thú cưng hiện nay tồn tại hai hướng tiếp cận chính:

  • Mô hình B2B: Tập trung liên kết các đơn vị cung cấp dịch vụ (spa, thú y, thức ăn). Nhược điểm là chi phí vận hành cao, khó giữ chân người dùng vì tần suất sử dụng dịch vụ thực tế không liên tục hàng ngày.
  • Mô hình B2C: Tập trung xây dựng cộng đồng, nâng cao trải nghiệm giải trí và chia sẻ để tạo tệp người dùng trung thành trước khi tích hợp dịch vụ thương mại. Dự án 4Pet lựa chọn mô hình B2C.
Tiêu chí Facebook Groups / Fanpage Pet Social Apps hiện có (B2B focus) Nền tảng 4Pet (B2C MVP)
Tính chuyên biệt Thấp (Mạng xã hội tổng hợp) Trung bình (Tập trung danh bạ dịch vụ) Rất cao (Tối ưu hóa cho thú cưng)
Tìm kiếm & Phân loại Kém, trôi bài viết nhanh chóng Cơ bản theo vị trí địa lý Nâng cao (Elasticsearch toàn văn)
Kiến trúc hệ thống Đóng kín, nguyên khối tập đoàn Đa số Monolithic truyền thống Microservices + CQRS + Event-Driven
Khả năng mở rộng N/A (Phụ thuộc nền tảng) Hạn chế khi tải đọc/ghi tăng đột biến Rất cao (Kubernetes Auto-scaling)
Giao tiếp liên dịch vụ Nội bộ proprietary REST API qua HTTP/1.1 gRPC (HTTP/2) + GraphQL Subscription

Dựa trên phương pháp MoSCoW, yêu cầu nghiệp vụ được phân cấp:

  • Must-have: Đăng nhập qua Facebook, hiển thị Story đa phương tiện, bình luận, thả tim, đẩy thông báo realtime, nhắn tin 1-1, tìm kiếm bài viết/người dùng.
  • Should-have: Đồng bộ hóa dữ liệu tức thời qua CDC, cơ chế tự động mở rộng Pod khi lưu lượng truy cập tăng (HPA).
  • Could-have: Lưu trữ đệm đa tầng bằng Redis, công cụ dòng lệnh trực quan K9s quản lý Kubernetes.
  • Won't-have (giai đoạn MVP): Đặt lịch khám thú y, sàn thương mại điện tử phụ kiện thú cưng.

Thiết kế hệ thống

Kiến trúc 4Pet được thiết kế theo hướng Event-Driven Microservices kết hợp CQRS, giải quyết triệt để sự mất cân bằng giữa tần suất đọc (Read) và ghi (Write) của các ứng dụng mạng xã hội.

                    +------------------------------------+
                    |        Client Layer (Flutter)      |
                    +------------------------------------+
                                      |
                         HTTP/2 - GraphQL / WebSocket
                                      v
                    +------------------------------------+
                    |      API Gateway / Ingress K8s     |
                    +------------------------------------+
                                      |
                   gRPC / Internal Protocol Buffers
                                      v
       +-----------------------------------------------------------+
       |                  Microservices Domain                     |
       |  [Auth Service] [Story Service] [Chat] [Notification]     |
       +-----------------------------------------------------------+
               |                                           ^
         Write Transaction                           Read / Query
               v                                           |
       +-----------------+                         +---------------+
       | PostgreSQL (DB) |                         | Elasticsearch |
       +-----------------+                         +---------------+
               |                                           ^
         WAL / Logical                                     |
               v                                           |
       +-----------------+      Kafka Topics       +---------------+
       | Debezium (CDC)  | ---> [Event Stream] --->| Kafka Streams |
       +-----------------+                         +---------------+

Technology Stack

  • Mobile Client: Flutter SDK (v2.x), Dart (v2.12+), thư viện quản lý trạng thái Provider/Bloc.
  • Backend Services: Node.js (v14.x LTS), Kotlin (v1.5+), ExpressJS, gRPC-Node.
  • API Protocol: GraphQL (Apollo Server/Client), gRPC (Google Protocol Buffers v3), HTTP/2.
  • Databases: PostgreSQL (v13.x - Transactional Read/Write), Elasticsearch (v7.12.x - Full-text Search Engine), Redis (v6.x - Caching & Session Store).
  • Event Streaming & CDC: Apache Kafka (v2.8.x), Debezium Connector (v1.5.x), Kafka Streams.
  • Infrastructure & DevOps: Docker (v20.10+), Kubernetes (v1.20+ trên Azure Kubernetes Service - AKS), Ingress NGINX, GitHub Actions, K9s, Docker Hub.

Database Schema & Model

Hệ thống phân tách cơ sở dữ liệu độc lập theo từng microservice:

  • Auth Service: Quản lý bảng accounts, users, social_accounts, followers (lưu trữ quan hệ đồ thị bạn bè).
  • Story Service: Quản lý bảng stories (chứa tiêu đề, trạng thái kiểm duyệt, timestamps), comments, story_media và comment_media.
  • Media Service: Quản lý bảng media (URL, loại mime, kích thước), liên kết hệ thống lưu trữ đám mây.
  • Reaction & Chat Services: Quản lý các sự kiện thả cảm xúc và phiên hội thoại (bảng conversations, messages).
-- DDL cấu trúc bảng Story (PostgreSQL)
CREATE TABLE stories (
    id VARCHAR(36) PRIMARY KEY,
    user_id VARCHAR(36) NOT NULL,
    caption TEXT,
    view_count INT DEFAULT 0,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);

CREATE TABLE story_media (
    id VARCHAR(36) PRIMARY KEY,
    story_id VARCHAR(36) NOT NULL,
    media_url VARCHAR(512) NOT NULL,
    media_type VARCHAR(20) NOT NULL, -- 'IMAGE' hoặc 'VIDEO'
    display_order INT DEFAULT 0,
    CONSTRAINT fk_story FOREIGN KEY (story_id) REFERENCES stories(id) ON DELETE CASCADE
);

API Specification

Truyền thông liên dịch vụ sử dụng gRPC với Protocol Buffers để đạt tốc độ serialize nhị phân nhanh và giảm băng thông.

syntax = "proto3";
package pet.social.story;

service StoryGrpcService {
  rpc GetStoryDetail (StoryRequest) returns (StoryResponse);
  rpc CreateStory (CreateStoryRequest) returns (StoryResponse);
}

message StoryRequest {
  string story_id = 1;
}

message StoryResponse {
  string id = 1;
  string user_id = 2;
  string caption = 3;
  repeated string media_urls = 4;
  int64 created_at = 5;
}

Phương pháp luận phát triển (Methodology)

Dự án áp dụng mô hình phát triển phần mềm linh hoạt Agile/Scrum, quản lý tiến độ và luồng công việc qua bảng Trello.

  • Sprint Cycle: 2 tuần/sprint, bao gồm các sự kiện Sprint Planning, Daily Standup, Sprint Review và Retrospective.
  • Định nghĩa Hoàn thành (Definition of Done - DoD): Tính năng phải vượt qua bộ kiểm thử tự động (Unit Test), hoàn thành tài liệu hóa API, xây dựng thành công Docker image qua CI pipeline và triển khai ổn định trên staging cluster.
  • Quản trị rủi ro: Rủi ro bất đồng bộ dữ liệu giữa SQL và Elasticsearch được kiểm soát bằng cơ chế ghi nhận offset chính xác của Kafka consumer group và thiết lập Dead Letter Queue (DLQ).

Implementation và kết quả

Quá trình phát triển và thuật toán cốt lõi

Quy trình phát triển chia làm 4 giai đoạn trọng điểm:

  1. Giai đoạn 1: Phân tích nghiệp vụ, thiết kế giao diện UI/UX trên Figma, dựng khung ứng dụng Flutter và thiết kế schema Database.
  2. Giai đoạn 2: Hiện thực hóa các Core Microservices (Auth, Story, Media) bằng Node.js và gRPC; tích hợp Gateway GraphQL.
  3. Giai đoạn 3: Thiết lập đường ống Change Data Capture (CDC) với Debezium và Kafka Streams; xây dựng engine tìm kiếm Elasticsearch.
  4. Giai đoạn 4: Cấu hình quy trình CI/CD GitHub Actions, khởi tạo cluster AKS và triển khai hạ tầng với Kubernetes.

Cấu hình CDC Pipeline với Debezium và PostgreSQL

Debezium đọc các thay đổi từ Logical Decoding WAL (Write-Ahead Logging) của PostgreSQL và đẩy trực tiếp thành các event JSON vào Kafka Topic:

{
  "name": "postgres-story-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "tasks.max": "1",
    "plugin.name": "pgoutput",
    "database.hostname": "postgres-service",
    "database.port": "5432",
    "database.user": "postgres",
    "database.password": "secret",
    "database.dbname": "pet_social_db",
    "database.server.name": "k8s_pg_source",
    "table.include.list": "public.stories,public.story_media"
  }
}

Xử lý Realtime với GraphQL Subscription và Kafka

// GraphQL Subscription Handler kết nối Kafka Consumer
const { RedisPubSub } = require('graphql-redis-subscriptions');
const pubsub = new RedisPubSub();

const resolvers = {
  Subscription: {
    newNotification: {
      subscribe: () => pubsub.asyncIterator(['NOTIFICATION_CREATED']),
    },
    messageSent: {
      subscribe: (_, { conversationId }) => 
        pubsub.asyncIterator([`MESSAGE_CHANNEL_${conversationId}`]),
    },
  },
  Mutation: {
    sendMessage: async (_, { input }, { kafkaProducer }) => {
      // 1. Lưu DB
      const message = await saveMessageToPostgres(input);
      // 2. Bắn Event vào Kafka Topic để xử lý CDC và đẩy realtime
      await kafkaProducer.send({
        topic: 'chat-events',
        messages: [{ value: JSON.stringify(message) }],
      });
      pubsub.publish(`MESSAGE_CHANNEL_${input.conversationId}`, { messageSent: message });
      return message;
    }
  }
};

Kiểm thử và đánh giá hiệu năng

Hệ thống được kiểm thử tải trọng (Load Testing) và đo đạc hiệu năng với công cụ Apache JMeter và k6:

  • Unit Test & Integration Test: Đạt độ bao phủ kiểm thử (Code Coverage) 82% trên các module nghiệp vụ cốt lõi.
  • So sánh REST API (HTTP/1.1) và gRPC (HTTP/2 Protocol Buffers):
    • Response Time: gRPC giảm 42,8% độ trễ mạng so với REST API truyền thống ở cùng mức tải 1.000 concurrent requests.
    • Throughput: gRPC tăng 65,4% khả năng xử lý thông lượng (requests per second) nhờ đóng gói nhị phân nhỏ gọn và cơ chế Multiplexing trên 1 kết nối TCP duy nhất.
  • Tốc độ đồng bộ CDC (PostgreSQL -> Elasticsearch): Độ trễ trễ đồng bộ (Replication Lag) đo được qua Kafka Streams đạt mức trung bình 120ms - 250ms, đảm bảo tính nhất quán dữ liệu cho nghiệp vụ tìm kiếm toàn văn.
Kịch bản kiểm thử Tải đồng thời REST (HTTP/1.1) Response Time gRPC (HTTP/2) Response Time Cải thiện (%)
Get Story Detail 100 req/s 145 ms 82 ms -43.4%
Search User/Story 500 req/s 320 ms (PostgreSQL Like) 58 ms (Elasticsearch CDC) -81.8%
Send Message 1,000 req/s 410 ms 195 ms -52.4%

Kết quả đạt được

  • Hoàn thiện 100% các tính năng MVP đề ra ban đầu: Story tương tác đa phương tiện, Chat 1-1, Notification, Discover và Search Engine.
  • Ứng dụng di động Flutter build thành công trên nền tảng Android, duy trì hoạt ảnh mượt mà ổn định ở mức 60 FPS.
  • Toàn bộ 7 microservices được docker hóa, quản lý triển khai qua 15 file cấu hình Kubernetes (Deployments, Services, ConfigMaps, Secrets, Ingress, HPA).
  • Quy trình CI/CD hoàn thiện: Tự động chạy unit test, build image và push lên Docker Hub trong thời gian trung bình 3 phút 45 giây cho mỗi commit.

Đổi mới và đóng góp

Đổi mới kỹ thuật

  1. Phân tách triệt để Read/Write với CDC (Change Data Capture): Thay vì sử dụng phương pháp Polling cơ sở dữ liệu truyền thống gây nghẽn I/O, dự án sử dụng Debezium bắt sự kiện thay đổi mức hàng trực tiếp từ Write-Ahead Log (WAL) của PostgreSQL. Cơ chế này giảm tải hơn 70% chi phí truy vấn database chính khi người dùng thực hiện tìm kiếm.
  2. Kafka Streams Model Aggregation: Dữ liệu từ nhiều bảng SQL phân mảnh (stories, users, media) được Kafka Streams tổng hợp theo thời gian thực thành document hoàn chỉnh trước khi nạp vào Elasticsearch, loại bỏ hoàn toàn các câu truy vấn JOIN phức tạp ở tầng ứng dụng.
  3. Mô hình giao tiếp mạng Hybrid (GraphQL + gRPC): Client giao tiếp với hệ thống thông qua GraphQL Gateway để tránh Over-fetching/Under-fetching dữ liệu, trong khi các Microservices nội bộ liên lạc bằng gRPC nhị phân qua HTTP/2, tối đa hóa thông lượng mạng nội bộ.
+--------------------------------------------------------------------------+
|                  ĐÓNG GÓP KỸ THUẬT NỔI BẬT CỦA 4PET                      |
|                                                                          |
|  1. Không Polling Database  -> Debezium CDC từ WAL (Giảm 70% I/O load)   |
|  2. Không Query N+1         -> GraphQL Gateway Resolver chuyên biệt      |
|  3. Không nghẽn REST        -> gRPC nhị phân nội bộ (Giảm 42.8% latency) |
|  4. Đồng bộ đa tầng         -> Kafka Streams làm phẳng Document Model    |
+--------------------------------------------------------------------------+

Đóng góp thực tiễn và học thuật

  • Đồ án chứng minh tính khả thi của việc kết hợp các công nghệ Cloud-Native phân tán phức tạp (Kafka, Kubernetes, Debezium, gRPC) vào bài toán mạng xã hội tại Việt Nam.
  • Cung cấp tài liệu tham khảo chi tiết và bộ source code chuẩn mực về quy trình triển khai CI/CD, đóng gói SDK dùng chung (4pet-sdk) và quản trị Kubernetes Cluster bằng K9s cho sinh viên và kỹ sư phần mềm.

Ứng dụng thực tế và triển khai

Chiến lược triển khai trên Azure Kubernetes Service (AKS)

Toàn bộ hệ thống được triển khai trên nền tảng điện toán đám mây Microsoft Azure thông qua dịch vụ Azure Kubernetes Service (AKS).

# 1. Khởi tạo Resource Group và AKS Cluster
az group create --name 4PetResourceGroup --location southeastasia
az aks create \
  --resource-group 4PetResourceGroup \
  --name 4PetCluster \
  --node-count 3 \
  --enable-addons monitoring \
  --generate-ssh-keys

# 2. Cấu hình context kubectl và triển khai Manifests
az aks get-credentials --resource-group 4PetResourceGroup --name 4PetCluster
kubectl apply -f k8s/secrets.yaml
kubectl apply -f k8s/configmaps.yaml
kubectl apply -f k8s/deployments/
kubectl apply -f k8s/services/
kubectl apply -f k8s/ingress.yaml
kubectl apply -f k8s/hpa.yaml

# Manifest Horizontal Pod Autoscaler (HPA) cho Story Service
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: story-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: story-service-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Phân tích hiệu quả kinh tế và lộ trình mở rộng

  • Hiệu quả hạ tầng: Việc sử dụng kiến trúc Microservices kết hợp HPA cho phép co giãn số lượng Pod linh hoạt theo thời gian thực (tự động mở rộng từ 2 lên 10 Pods khi CPU vượt 70%), giúp tiết kiệm đến 40% chi phí duy trì máy chủ trong các khung giờ thấp điểm so với hạ tầng máy chủ ảo (VM) cố định.
  • Lộ trình phát triển sản phẩm:
    • Giai đoạn 1 (Hiện tại): Vận hành ổn định phiên bản B2C MVP, thu hút 10.000 người dùng đầu tiên.
    • Giai đoạn 2 (6–12 tháng): Mở rộng tích hợp tính năng gắn thẻ thông minh (Pet Tag), nhận diện giống thú cưng bằng AI Vision và phát triển mạng lưới đối tác B2B (bảo hiểm thú cưng, spa, trạm y tế).
    • Giai đoạn 3 (12–24 tháng): Khai thác nền tảng B2B2C toàn diện, tích hợp sàn thương mại điện tử chuyên biệt và dịch vụ bác sĩ thú y tư vấn từ xa (Telehealth for Pets).

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Tính nhất quán sau cùng (Eventual Consistency): Do tách biệt luồng ghi (PostgreSQL) và luồng đọc (Elasticsearch) thông qua CDC và Kafka, dữ liệu tìm kiếm sẽ có độ trễ khoảng 100–250ms trước khi được đồng bộ hoàn toàn.
  • Tài nguyên phần cứng môi trường phát triển: Kiến trúc Microservices với nhiều thành phần phụ thuộc (Kafka, Zookeeper, Schema Registry, Debezium, Elasticsearch, PostgreSQL, Redis) đòi hỏi máy tính lập trình viên có cấu hình tối thiểu 16GB–32GB RAM để chạy đầy đủ môi trường local.
  • Chi phí nén và chuyển đổi định dạng Media: Giai đoạn MVP xử lý video trực tiếp chưa tích hợp CDN chuyên dụng và module chuyển mã đa luồng (HLS/DASH transcoding), có thể gây tốn băng thông máy chủ khi lưu lượng video tăng cao.

Hướng phát triển trong tương lai

  1. Tích hợp giải pháp mạng phân phối nội dung (Cloudflare/AWS CloudFront CDN) và dịch vụ xử lý video streaming chuyên nghiệp (AWS Elastic Transcoder hoặc FFmpeg Worker cluster).
  2. Xây dựng mô hình học máy gợi ý bài viết (Recommendation System) dựa trên hành vi tương tác và giống loài thú cưng của người dùng.
  3. Bổ sung các tính năng phục vụ chăm sóc thực tế: Sổ theo dõi tiêm phòng định kỳ, cảnh báo tìm kiếm thú cưng thất lạc dựa trên định vị địa lý (GPS Geofencing).

Đối tượng hưởng lợi

+------------------------------------------------------------------------+
|                         ĐỐI TƯỢNG HƯỞNG LỢI                            |
|                                                                        |
|  [Sinh viên]   -> Tham khảo kiến trúc Microservices, CQRS, CDC chuẩn   |
|  [Kỹ sư phần mềm] -> Mã nguồn tích hợp gRPC, Kafka Streams, K8s AKS   |
|  [Doanh nghiệp]   -> Mô hình kinh tế B2C mở đường B2B cho Pet Care     |
|  [Nhà nghiên cứu] -> Dữ liệu benchmark thực tế HTTP/1 vs HTTP/2 gRPC   |
+------------------------------------------------------------------------+
  • Sinh viên ngành CNTT/Kỹ thuật Phần mềm: Có được tài liệu nghiên cứu thực tế, rõ ràng về cách áp dụng các mẫu thiết kế phức tạp (CQRS, Event-Driven, CDC) vào dự án phần mềm hoàn chỉnh thay vì chỉ dừng lại ở lý thuyết sách vở.
  • Kỹ sư và Lập trình viên Backend/Mobile: Tiếp cận bộ khung kiến trúc hoàn chỉnh kết hợp Flutter, GraphQL, gRPC và Kubernetes; nắm vững cách thức triển khai CI/CD thực tế trên nền tảng đám mây Azure.
  • Doanh nghiệp và Nhà đầu tư ngành Thú cưng: Sở hữu nền tảng công nghệ sẵn sàng mở rộng quy mô để tiếp cận tập khách hàng mục tiêu, tối ưu hóa chi phí quảng cáo và phân phối dịch vụ chăm sóc thú cưng trực tiếp.
  • Nhà nghiên cứu học thuật: Nguồn dữ liệu kiểm thử thực nghiệm giá trị so sánh chi tiết giữa REST API và gRPC, cũng như đánh giá độ trễ của kỹ thuật Change Data Capture trong môi trường container hóa.

Câu hỏi thường gặp (FAQ)

1. Yêu cầu hệ thống tối thiểu để tự triển khai và chạy thử nghiệm dự án là gì?

Hạ tầng phát triển cục bộ yêu cầu máy tính chạy hệ điều hành Linux (Ubuntu 20.04+), macOS hoặc Windows (hỗ trợ WSL2), cấu hình tối thiểu CPU 4 Cores, 16GB RAM (khuyến nghị 32GB RAM để vận hành toàn bộ Docker Compose stack gồm Kafka, Elasticsearch, Debezium, Postgres). Trên Cloud, AKS Cluster cần tối thiểu 3 Node (Standard_B2s hoặc Standard_D2s_v3).

2. Hệ thống xử lý thế nào khi có hàng nghìn người cùng thả tim hoặc bình luận đồng thời?

Hệ thống sử dụng cơ chế xử lý bất đồng bộ qua Kafka Message Queue. Các thao tác ghi (Command) được đẩy trực tiếp vào Kafka Topic với độ trễ ghi cực thấp (<5ms), sau đó các worker xử lý ghi nhận dữ liệu vào PostgreSQL theo lô (batching) và cập nhật số lượng đếm qua bộ nhớ đệm Redis, ngăn chặn hoàn toàn tình trạng nghẽn khóa dòng (Row-level lock) trong cơ sở dữ liệu.

3. Tại sao dự án không sử dụng hoàn toàn cơ sở dữ liệu NoSQL (như MongoDB) cho toàn bộ hệ thống?

4Pet lựa chọn mô hình lưu trữ đa hình (Polyglot Persistence). PostgreSQL được sử dụng cho dữ liệu nghiệp vụ chính (User, Auth, Billing) nhằm đảm bảo tính toàn vẹn giao dịch (ACID) và ràng buộc quan hệ chặt chẽ. Trong khi đó, Elasticsearch chuyên biệt hóa cho việc tìm kiếm toàn văn tốc độ cao và Redis phục vụ bộ nhớ tạm thời gian thực.

4. Chi phí vận hành hạ tầng Kubernetes trên Azure (AKS) được kiểm soát ra sao?

Hệ thống tận dụng cơ chế Horizontal Pod Autoscaler (HPA) kết hợp Kubernetes Cluster Autoscaler. Vào các khung giờ thấp điểm ban đêm, số lượng Pod của từng dịch vụ được giảm về mức tối thiểu (1–2 Pods) và số lượng VM Node của AKS tự động co về mức tối thiểu, giúp tiết kiệm chi phí băng thông và điện toán từ 35% đến 40%.

5. Dữ liệu giữa PostgreSQL và Elasticsearch có nguy cơ bị lệch khi có sự cố mạng không?

Không. Debezium theo dõi nhật ký WAL của PostgreSQL và lưu vết chỉ số Offset đã đọc vào một Kafka Topic nội bộ chuyên dụng. Khi xảy ra sự cố mạng hoặc sập container, Debezium và Kafka Consumer sẽ tự động phục hồi và tiếp tục đồng bộ chính xác từ vị trí Offset cuối cùng đã xác nhận (Committed Offset), đảm bảo không làm mất mát hay sai lệch sự kiện dữ liệu.

Kết luận

Khóa luận tốt nghiệp "Xây dựng mạng xã hội cho những người yêu thú cưng (4Pet)" của sinh viên Nguyễn Duy Cương và Vi Chí Thiện đã hoàn thành xuất sắc các mục tiêu đề ra. Đề tài không chỉ mang lại một giải pháp ứng dụng di động trực quan, giàu tiện ích cho cộng đồng người nuôi thú cưng tại Việt Nam, mà còn khẳng định giá trị công nghệ vượt trội thông qua việc làm chủ kiến trúc Microservices hiện đại, kỹ thuật Change Data Capture tiên tiến với Debezium, cơ chế giao tiếp gRPC hiệu năng cao và năng lực vận hành tự động hóa trên Azure Kubernetes Service.

Sự kết hợp hài hòa giữa tư duy sản phẩm thực tế (Lean MVP/Scrum) và kiến trúc kỹ thuật chuẩn mực hướng dịch vụ đã tạo nên nền tảng vững chắc cho 4Pet tiếp tục phát triển, mở rộng quy mô và thương mại hóa thành công trong tương lai.