Có một câu hỏi mà bất kỳ Technical Lead nào xây dựng sản phẩm SaaS cũng sẽ phải đối mặt sớm hay muộn: Khi nào thì kiến trúc hiện tại của mình trở thành vật cản thay vì đòn bẩy?

Atlassian đối mặt câu hỏi đó vào giai đoạn họ vận hành Jira và Confluence cho hàng chục nghìn khách hàng doanh nghiệp. Câu trả lời của họ không phải là rewrite toàn bộ hệ thống — mà là thêm một lớp trừu tượng thông minh vào đúng chỗ. Đây là bài học kiến trúc mà mình muốn phân tích kỹ.

Vấn đề: Khi Single-Tenant Bắt Đầu “Đau”

Trong mô hình single-tenant truyền thống, mỗi khách hàng (tenant) được cấp phát tài nguyên riêng biệt — compute node riêng, database riêng, stack riêng. Nghe có vẻ sạch sẽ và an toàn. Nhưng ở quy mô hàng nghìn tenant, ba vấn đề nổi lên không thể bỏ qua.

Fault isolation ngược chiều. Mỗi compute node gắn chặt với một tenant cụ thể. Khi node đó gặp sự cố, đúng một khách hàng đó mất service ngay lập tức. Không có failover tự động, không có node nào khác đủ context để tiếp quản. Trong mô hình này, “fault isolation” thực chất lại tạo ra single point of failure cho từng tenant.

Rollout 24 giờ. Để deploy một phiên bản mới, team phải lần lượt cập nhật từng tenant. Với hàng chục nghìn tenant, quá trình này kéo dài đến 24 giờ. Trong khoảng thời gian đó, hệ thống tồn tại ở nhiều version khác nhau song song — một bài toán tương thích ngược cực kỳ phức tạp và rủi ro.

Lãng phí tài nguyên. Mỗi tenant nhỏ vẫn chiếm trọn một compute node. Những node này idle phần lớn thời gian, đặc biệt với tenant ít hoạt động. Khi tenant lớn cần burst capacity, hệ thống không có cơ chế tái phân bổ từ node của tenant nhỏ sang.

Ba vấn đề này không độc lập — chúng cộng hưởng. Rollout chậm đồng nghĩa với việc lỗi tồn tại lâu hơn trong production. Tài nguyên bị khóa cứng đồng nghĩa với chi phí vận hành tăng tuyến tính theo số tenant. Đây là bẫy kiến trúc điển hình khi một mô hình đơn giản và hiệu quả ở quy mô nhỏ bắt đầu tạo ra ma sát theo hàm mũ.

Quyết Định Thiết Kế: Tách Biệt Compute Khỏi State

Atlassian đưa ra một quyết định kiến trúc cốt lõi: stateless compute. Mọi compute node đều có thể phục vụ bất kỳ tenant nào. Không node nào “thuộc về” một tenant cụ thể.

Quyết định này giải quyết cả ba vấn đề trên:

  • Khi một node chết, bất kỳ node nào khác trong cluster đều có thể tiếp quản request của tenant đó ngay lập tức.
  • Deployment chỉ cần rolling update trên compute layer, không cần xử lý từng tenant riêng lẻ.
  • Load balancer có thể phân phối traffic linh hoạt theo capacity thực tế, không bị ràng buộc bởi tenant ownership.

Nhưng đây là điểm then chốt: database vẫn được giữ riêng theo từng tenant. Atlassian không pool database vì lý do compliance, data isolation, và để tránh “noisy neighbor” ở tầng lưu trữ. Chỉ tầng compute mới được shared.

Điều này tạo ra một câu hỏi mới: nếu mọi node đều stateless, làm thế nào một node biết cần kết nối đến database nào khi nhận request từ tenant X?

Tenant Context Service: Trái Tim Của Kiến Trúc Mới

Đây là lúc Tenant Context Service (TCS) xuất hiện.

TCS là một middleware layer đứng giữa compute node và database. Nhiệm vụ của nó: nhận một tenant identifier từ request, trả về thông tin kết nối đến đúng database của tenant đó. Đơn giản về concept, nhưng phức tạp về implementation khi nó xử lý hơn 30.000 request mỗi giây ở production.

flowchart LR
    U([User Request]) --> LB[Load Balancer]
    LB --> CN[Stateless Compute Node]
    CN -->|"tenant_id lookup"| TCS[Tenant Context Service]
    TCS -->|cache hit| Cache[(TCS Local Cache)]
    TCS -->|cache miss| DDB[(DynamoDB\nSource of Truth)]
    DDB --> TCS
    Cache --> TCS
    TCS -->|"db connection info"| CN
    CN --> TDB[(Tenant Database)]

Flow hoạt động như sau:

  1. Request đến mang theo tenant identifier (thường embedded trong subdomain hoặc header).
  2. Compute node gọi TCS với tenant ID.
  3. TCS kiểm tra local cache. Nếu có, trả về ngay — latency micro-giây.
  4. Nếu cache miss, TCS query DynamoDB để lấy thông tin kết nối của tenant.
  5. Compute node nhận connection string, kết nối đến đúng tenant database, xử lý request.

Ở quy mô 30.000 req/sec, cache hit rate gần như phải đạt 99%+ để không biến TCS thành bottleneck. Đây là lý do Atlassian phải giải quyết bài toán cache invalidation một cách nghiêm túc.

CQRS Trong Thực Tế: Không Phải Lý Thuyết

CQRS (Command Query Responsibility Segregation) thường được giải thích bằng diagram trừu tượng. Cách Atlassian áp dụng nó cụ thể hơn nhiều.

Write path (Commands): DynamoDB là source of truth duy nhất. Mọi thay đổi cấu hình tenant — thêm tenant mới, cập nhật database endpoint, thay đổi plan — đều được ghi vào DynamoDB với strong consistency. Đây là “sự thật” duy nhất của hệ thống.

Read path (Queries): Các TCS cluster được triển khai theo region, mỗi cluster giữ một bản sao của tenant data trong memory. Reads được phục vụ từ đây với latency thấp, không cần round-trip đến DynamoDB mỗi lần.

Synchronization: Đây là phần thú vị. Atlassian dùng AWS Kinesis Streams để propagate changes từ DynamoDB đến các TCS cluster theo thời gian thực. Khi DynamoDB có record mới hoặc update, event được đẩy vào Kinesis. Các TCS cluster consume stream này và cập nhật in-memory state của mình. Độ trễ chỉ tính bằng mili-giây.

Cache invalidation: Với các thay đổi cấu hình khẩn cấp — ví dụ tenant bị suspended hoặc database migration — Atlassian dùng AWS SNS để broadcast invalidation signal đến tất cả TCS nodes ngay lập tức. Node nhận signal sẽ evict entry đó khỏi cache, buộc lookup lại từ DynamoDB ở request tiếp theo.

Kiến trúc này chấp nhận eventual consistency trên read path (TCS cluster có thể lag vài mili-giây so với DynamoDB) đổi lấy throughput và latency tốt hơn nhiều. Đây là trade-off có ý thức, không phải lỗi thiết kế.

Aha Moment: Họ Không Rewrite Jira

Đây là phần mình thấy ấn tượng nhất về cách tiếp cận của Atlassian.

Jira và Confluence là những codebase phức tạp, nhiều triệu dòng code, được build theo mô hình single-tenant qua nhiều năm. Rewrite chúng từ đầu sẽ tốn nhiều năm, rủi ro cực cao, và gần như chắc chắn sẽ introduce regressions không thể đoán trước.

Atlassian không làm vậy. Họ thêm TCS như một abstraction layer bên ngoài Jira/Confluence. Application code bên trong vẫn nghĩ rằng nó đang kết nối đến “the database” — TCS inject đúng connection string trước khi request đến application layer.

Đây là pattern Strangler Fig và Abstraction Layer kết hợp. Thay vì thay thế legacy system, bạn thêm một lớp routing thông minh phía trước nó. Legacy code không biết gì về multi-tenancy — TCS xử lý toàn bộ phần đó.

Kết quả: migration diễn ra mà không cần chạm vào hàng triệu dòng code application, không cần feature freeze, không cần big bang cutover.

Những Pattern Bất Kỳ Team Nào Cũng Có Thể Học

Nhìn lại toàn bộ hành trình của Atlassian, mình rút ra vài pattern có thể áp dụng ngay cả khi bạn không vận hành ở quy mô Atlassian.

Stateless compute là baseline, không phải optimization. Nếu compute node của bạn giữ state local, bạn đang tự giới hạn khả năng scale và failover. Đây không phải vấn đề của “khi nào lớn hơn mới cần giải quyết” — đây là quyết định kiến trúc cần đưa ra từ sớm.

Tách routing logic khỏi business logic. TCS làm đúng một việc: map tenant ID sang connection info. Nó không biết gì về business logic của Jira hay Confluence. Sự tách biệt này cho phép cả hai evolve độc lập.

CQRS không nhất thiết phải phức tạp. Pattern cốt lõi là: một nguồn sự thật duy nhất cho writes, replica/cache tối ưu cho reads, và một cơ chế propagation rõ ràng ở giữa. DynamoDB + Kinesis + in-memory cache là một implementation cụ thể, không phải định nghĩa của pattern.

Abstraction layer là công cụ migration mạnh nhất. Khi bạn cần thay đổi cách hệ thống hoạt động mà không thể rewrite toàn bộ, thêm một lớp trung gian kiểm soát routing/context thường là đường đi ít đau nhất.

Góc Nhìn Của Một Technical Lead

Sau 15 năm làm việc với .NET, cloud, và gần đây là AI workloads, mình nhận ra rằng những vấn đề như Atlassian gặp phải không phải đặc thù của công ty lớn. Bất kỳ SaaS nào vượt qua giai đoạn early-stage đều sẽ đụng phải bài toán tương tự ở một dạng nào đó.

Điều mình sẽ áp dụng từ case study này: khi gặp yêu cầu thay đổi kiến trúc lớn, câu hỏi đầu tiên không phải là “rewrite hay migrate?” mà là “có thể thêm abstraction layer ở đâu để giảm scope thay đổi xuống mức nhỏ nhất không?” TCS của Atlassian là câu trả lời cho câu hỏi đó — một service nhỏ, well-defined, giải quyết đúng một vấn đề, cho phép phần còn lại của hệ thống không cần biết gì về sự thay đổi bên dưới.

Với các project .NET mình đang tư vấn, pattern này translates trực tiếp: thay vì inject tenant context qua dependency injection framework theo cách thông thường, có thể externalize tenant resolution ra một service riêng biệt — làm cho nó scalable và cacheable độc lập với application logic.

Kết Luận

Hành trình của Atlassian từ single-tenant đến multi-tenant không phải là câu chuyện về việc viết lại một hệ thống lớn. Đó là câu chuyện về việc hiểu đúng vấn đề cần giải quyết — rồi thêm đúng một lớp trừu tượng vào đúng chỗ.

Scale không chỉ là thêm server. Đó là thay đổi cách bạn quản lý state, data, và tenant context. Thêm server mà không thay đổi kiến trúc chỉ là trì hoãn vấn đề. Atlassian hiểu điều đó, và TCS là bằng chứng.

Nếu bạn đang xây dựng SaaS và chưa nghĩ đến tenant routing layer, đây là thời điểm tốt để bắt đầu — trước khi quy mô buộc bạn phải.

Xuất nội dung

Bình luận