Khi nhắc đến Spotify, nhiều người sẽ nghĩ ngay đến recommendation system, streaming hay machine learning. Nhưng để những tính năng đó có thể phát triển với tốc độ rất nhanh, Spotify đã phải giải quyết một bài toán còn khó hơn:
Làm thế nào để hàng trăm kỹ sư và hàng chục đội phát triển có thể triển khai sản phẩm mỗi ngày mà không phụ thuộc lẫn nhau?
Đây chính là chủ đề của bài viết Backend Infrastructure at Spotify. Điều thú vị là bài viết này được xuất bản từ năm 2013, nhưng rất nhiều tư tưởng trong đó vẫn là nền tảng của Platform Engineering và Developer Platform ngày nay.

​
Thách thức lớn nhất không phải là hạ tầng, mà là tốc độ phát triển

Spotify phát triển rất nhanh. Số lượng người dùng tăng liên tục. Số lượng backend service ngày càng nhiều, số lượng nền tảng client (iOS, Android, Desktop, Web…) cũng mở rộng không ngừng. Đồng thời, số lượng squad (nhóm phát triển) cũng tăng theo từng năm. Khi quy mô tổ chức tăng lên, một vấn đề mới xuất hiện. Nếu mỗi lần một đội muốn deploy service mới đều phải chờ đội Infrastructure cấp máy chủ, chờ DBA tạo database hoặc chờ Operations cấu hình hệ thống, tốc độ phát triển sẽ giảm rất nhanh.
Theo Spotify, bottleneck lớn nhất của một công ty công nghệ quy mô lớn không phải CPU hay RAM mà chính là con người.

​
Spotify đặt Autonomous Squad làm trung tâm

Một trong những triết lý nổi tiếng nhất của Spotify là Autonomous Squad. Mỗi squad giống như một startup nhỏ. Họ sở hữu toàn bộ vòng đời của một tính năng, từ frontend, backend cho tới dữ liệu và vận hành. Điều này giúp đội phát triển có thể tự đưa ra quyết định và triển khai sản phẩm mà không phải phụ thuộc quá nhiều vào các nhóm khác. Nhưng để autonomous thực sự hoạt động, chỉ trao quyền là chưa đủ. Họ còn cần một hạ tầng đủ tốt để mọi đội đều có thể tự phục vụ (self-service).

​
Transparent Code: Mọi người đều có thể sửa code của nhau

Một ý tưởng khá thú vị của Spotify là Transparent Code Model. Toàn bộ source code của Spotify đều được chia sẻ nội bộ. Không có khái niệm “đây là code của team A nên team B không được sửa”. Nếu một squad bị chặn vì cần một thay đổi nhỏ ở service của đội khác, họ có thể tự sửa, tạo pull request và tiếp tục công việc thay vì phải chờ nhiều ngày. Dĩ nhiên, mỗi repository vẫn có owner chịu trách nhiệm review và bảo trì chất lượng code. Triết lý này giúp giảm đáng kể những điểm nghẽn trong quá trình phát triển.

​
Self-service Infrastructure: Muốn gì thì tự tạo

Spotify tin rằng mọi tài nguyên hạ tầng nên được cung cấp dưới dạng self-service. Một squad không nên phải gửi ticket để:
  • Xin server
  • Xin database
  • Xin storage
  • Xin queue
  • Xin cấu hình
Thay vào đó, họ có thể tự tạo những tài nguyên cần thiết thông qua nền tảng nội bộ. Ngày nay chúng ta gọi đây là Internal Developer Platform (IDP). Nhưng từ năm 2013, Spotify đã đi theo hướng này.

​
Chia hệ thống theo Feature thay vì Layer

Đây có lẽ là một trong những tư tưởng quan trọng nhất của Spotify. Thay vì chia team theo:
  • Frontend
  • Backend
  • Database
  • Operations
Spotify chia theo Feature. Ví dụ:
Một squad phụ trách Playlist. Họ chịu trách nhiệm toàn bộ tính năng đó, từ giao diện trên iOS, Android, Web cho đến backend service, batch processing trong Hadoop và cả hệ thống recommendation liên quan.
Điều này mang lại rất nhiều lợi ích. Nếu tính năng Playlist gặp sự cố, các tính năng khác như Search hay Radio vẫn hoạt động bình thường. Mỗi squad cũng hiểu rất rõ sản phẩm mình phụ trách, giúp việc A/B Testing, theo dõi dữ liệu và cải tiến tính năng diễn ra nhanh hơn. Đây cũng là một cách cô lập lỗi (fault isolation) rất hiệu quả.

​
Infrastructure phải giúp Developer chạy nhanh hơn

Sau khi chia hệ thống theo feature, câu hỏi tiếp theo là:
Infrastructure cần làm gì để hỗ trợ các squad?
Theo Spotify, platform không nên trở thành một điểm nghẽn mới. Ngược lại, nó phải giúp developer triển khai dịch vụ nhanh hơn, mở rộng dễ hơn và giảm tối đa các thao tác thủ công. Bài viết tập trung vào năm thành phần chính của backend infrastructure.
1

1. Provisioning: Triển khai ở đâu cũng giống nhau

Một service mới có thể chạy trong datacenter riêng của Spotify hoặc trên public cloud. Mục tiêu của platform là giảm tối đa sự khác biệt giữa hai môi trường này.Developer không cần quan tâm service đang chạy ở đâu. Họ chỉ cần triển khai ứng dụng, còn hạ tầng phía dưới sẽ đảm nhận việc cấp phát tài nguyên và cấu hình môi trường phù hợp.
2

2. Storage: Không có một database phù hợp cho mọi bài toán

Spotify không cố xây một hệ thống lưu trữ duy nhất. Thay vào đó, họ cung cấp nhiều lựa chọn như:
  • Cassandra
  • PostgreSQL
  • Memcached
Mỗi feature sẽ chọn giải pháp phù hợp với workload của mình.Ví dụ, một tính năng cần khả năng ghi phân tán có thể chọn Cassandra, trong khi những bài toán quan hệ vẫn phù hợp với PostgreSQL.Điều đáng chú ý là Spotify không cố che giấu mọi sự phức tạp. Nếu một service cần sharding, chính squad đó sẽ chịu trách nhiệm thiết kế cách shard dữ liệu. Platform chỉ giúp tự động hóa việc triển khai cluster, replication và failover.
3

3. Messaging: Mọi service đều giao tiếp qua một lớp chung

Backend của Spotify sử dụng ba mô hình giao tiếp chính:
  • Request/Reply
  • Messaging
  • Publish/Subscribe
Để tối ưu độ trễ, họ xây dựng một messaging layer riêng có overhead rất thấp. Hệ thống này còn được thiết kế để bổ sung thêm các khả năng như routing khi xảy ra lỗi, load balancing và đảm bảo khả năng gửi thông điệp đáng tin cậy trong tương lai. Ý tưởng rất rõ ràng:Infrastructure phải giải quyết bài toán giao tiếp chung để từng squad không phải tự xây lại từ đầu.
4

4. Capacity Planning: Scale phải là chuyện bình thường

Lưu lượng truy cập Spotify tăng liên tục. Mỗi squad phải đảm bảo service của mình có thể xử lý được lượng traffic ngày càng lớn. Ban đầu, các đội có thể theo dõi hệ thống thủ công và tự mở rộng khi cần.Tuy nhiên, Spotify cũng xây dựng hạ tầng hỗ trợ auto scaling, dashboard và alert để giúp việc mở rộng diễn ra tự động hơn.Điều này cho thấy một tư duy khá thực tế:
  • Auto Scaling rất hữu ích.
  • Nhưng nó không thay thế hoàn toàn việc theo dõi và tối ưu hệ thống của con người.
5

5. Cô lập lỗi giữa các service

Khi số lượng microservice tăng lên, các service bắt đầu gọi lẫn nhau ngày càng nhiều. Nếu không cẩn thận, một service bị lỗi có thể kéo theo hàng loạt service khác. Spotify giải quyết bằng nhiều cơ chế bảo vệ:
  • Rate Limiting
  • Permission System
  • Chạy các service trên những server hoặc máy ảo riêng biệt
  • Giới hạn lưu lượng mặc định giữa các service
Nếu một squad muốn gửi lượng request lớn hơn bình thường tới service của đội khác, họ cần phối hợp trước thay vì để hệ thống tự quá tải.Đây là một ví dụ rất sớm về việc xây dựng guardrails trong Platform Engineering.

​
Open Source là một quyết định chiến lược

Spotify ưu tiên sử dụng phần mềm mã nguồn mở thay vì giải pháp thương mại. Lý do không chỉ nằm ở chi phí. Quan trọng hơn, họ có thể tự sửa, tối ưu và đóng góp trở lại cho cộng đồng khi gặp giới hạn về hiệu năng hoặc khả năng mở rộng. Theo bài viết, Spotify từng đóng góp cho nhiều dự án như Apache Cassandra và ZeroMQ vì đây đều là những thành phần cốt lõi trong hệ thống backend của họ.

​
Những bài học đáng học từ Backend Infrastructure của Spotify

Điều thú vị nhất của bài viết không nằm ở Cassandra hay PostgreSQL. Bài học lớn hơn là cách Spotify thiết kế tổ chức và hạ tầng để hỗ trợ nhau. Một vài nguyên tắc rất đáng học là:

Các nguyên tắc cốt lõi

  • Chia hệ thống theo feature thay vì theo tầng kỹ thuật.
  • Xây dựng Self-service Platform để developer không phải chờ đợi.
  • Cung cấp nhiều lựa chọn về storage thay vì ép mọi workload dùng cùng một công nghệ.
  • Coi Infrastructure là sản phẩm nội bộ, nơi developer chính là khách hàng.
  • Thiết kế hệ thống sao cho các squad có thể phát triển độc lập và lỗi của một service không lan sang toàn hệ thống.

​
Kết luận

Nếu chỉ nhìn vào công nghệ, bài viết này có vẻ khá cũ. Nhưng nếu nhìn ở góc độ tư duy kiến trúc, rất nhiều ý tưởng trong đó vẫn là nền tảng của các tổ chức kỹ thuật hiện đại. Những khái niệm như Platform Engineering, Internal Developer Platform, Golden Path, Self-service Infrastructure hay Developer Experience đều có thể thấy bóng dáng trong cách Spotify xây dựng backend của mình từ hơn một thập kỷ trước. Có lẽ bài học lớn nhất từ Spotify là:
Một hạ tầng tốt không phải là hạ tầng có nhiều công nghệ nhất. Đó là hạ tầng giúp hàng trăm đội ngũ có thể phát triển nhanh, độc lập và gần như không phải chờ đợi nhau.