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.

1. 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.

2. 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.

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 / queue 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).

3. 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. Đây cũng là một cách cô lập lỗi (fault isolation) rất hiệu quả.

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

Theo Spotify, platform không nên trở thành một điểm nghẽn mớ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 5 thành phần chính:

1. Provisioning: Triển khai ở đâu cũng giống nhau Developer không cần quan tâm service đang chạy ở đâu (Datacenter hay Cloud). 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.

2. Storage: Không có một database phù hợp cho mọi bài toán Spotify cung cấp nhiều lựa chọn như Cassandra, PostgreSQL, Memcached. Một tính năng cần ghi phân tán sẽ chọn Cassandra, tính toán quan hệ sẽ chọn PostgreSQL. Spotify không cố che giấu sự phức tạp; nếu service cần sharding, chính squad đó sẽ chịu trách nhiệm thiết kế cách shard dữ liệu.

3. Messaging: Mọi service đều giao tiếp qua một lớp chung Họ xây dựng một messaging layer riêng có overhead rất thấp để tối ưu độ trễ và giải quyết bài toán giao tiếp chung (Request/Reply, Pub/Sub) để từng squad không phải tự xây lại từ đầu.

4. Capacity Planning: Scale phải là chuyện bình thường Spotify xây dựng hạ tầng hỗ trợ auto scaling, dashboard và alert. Tuy nhiên, họ thực tế nhận định: 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. Cô lập lỗi giữa các service Nếu một service lỗi, nó có thể kéo theo hàng loạt service khác. Spotify dùng Rate Limiting, Permission System và giới hạn lưu lượng để bảo vệ. Nếu một squad muốn gửi lượng request lớn 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.

Kết luận Nếu chỉ nhìn vào công nghệ, bài viết từ 2013 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 hay Developer Experience đều có bóng dáng từ cách Spotify xây dựng hệ thống hơn một thập kỷ trước.

Bài học lớn nhất từ Spotify: 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.