Meta 如何构建 Threads 的基础设施
Meta 关于构建 Threads 基础设施的工程文章引发了争论：这个类 Twitter 服务究竟是在蓬勃发展，还是基本上靠 Instagram 的庞大用户基础和交叉推广撑着。评论者一边讨论其技术基础——基于 MySQL 的存储、ZippyDB 和 Async 等内部系统，以及与开源栈的比较——一边又关注用户层面的现实问题，例如性能缓慢、煽动愤怒的推荐内容，以及激进的数据收集或验证流程。许多人认为 Threads 既是争夺文本社交媒体的战略举措，也可能成为 AI 的数据来源；另一些人则担心它对 fediverse 的影响，并更偏好 Mastodon 和 Bluesky 等替代方案。
Threads 的采用情况与可行性
- 一些评论者称 Threads “死了””或“靠生命维持”，认为它是被 Instagram 的激进推广强行撑起来的，且缺乏文化存在感（在 Meta 应用之外很少看到截图/链接）。
- 也有人反驳说，它在几天内就达到了 1 亿注册用户，月活约 1 亿，在应用商店排名接近前列，并且流量趋势向上，因此“出生即死亡”的说法并不准确。
- 指标之争：批评者说 MAU 可能包含误触 Instagram 的点击；支持者则将 MAU 与 Twitter 的历史规模相比较，认为表现相当不错。
Web 访问、ActivityPub 与 fediverse
- 不同地区体验不同：有些用户可以不通过应用或账户在网页上浏览 Threads（尤其是在欧盟），而另一些人仍会被强制进入应用完成设置。
- ActivityPub 集成被讨论为一种可使用任意客户端并实现联邦互联的潜在方式；一些人持乐观态度，也有人非常怀疑 Meta 会真正全面开放。
- fediverse/Mastodon 用户担心 Meta 可能会用主流内容淹没小众社区。
用户体验与内容质量
- 反馈两极分化：有些人觉得 Threads 很“轻松”，比 X/Twitter 更适合；另一些人则认为信息流充斥着煽动愤怒的内容、反 Musk 帖子，以及低价值的“技术”自我推销。
- 推荐质量普遍受到批评；要想让信息流可用，往往需要大量屏蔽/隐藏操作。
- 还有关于色情机器人和相较 X/Twitter 更慢的性能的抱怨。
- 一些组织尝试使用 Threads，发现其互动效果不如 LinkedIn、Instagram，甚至不如 Mastodon。
隐私、封禁与数据收集担忧
- 多个报告称，在创建 Instagram/Threads 账户时会遭遇即时或不透明的封禁，通常与用户觉得侵扰的手机和人脸验证流程有关。
- 有人认为这些大概率是反机器人或 KPI 驱动系统造成的无意副作用；也有人怀疑这是为提取更多个人数据而施加的软性压力，并指出此前的隐私问题和 GDPR 方面的紧张关系。
- 普遍存在对企业社交网络的不信任，以及对 Mastodon 的偏好或干脆完全避开 Meta。
Meta 的角色与公司行为
- 观点分裂：有人把 Meta 看作在推动一种联邦式社交协议，另一些人则认为它像一家 “Walmart” 式巨头，可能会扼杀更小的参与者。
- 一些人拒绝使用 Meta 产品，理由是 Facebook/Instagram 对心理健康的影响，以及反对为 Meta 提供财务支持。
- Meta 将 Threads 描述为“类似初创公司”的项目，这一点受到批评，因为它高度依赖现有的庞大基础设施；基础设施团队被临时通知，也被视为不尊重。
基础设施栈与技术讨论
- 人们赞赏 MySQL 加上键值存储（例如 ZippyDB、TAO）能扩展到多大规模；还有人将其与“关系存在 MySQL，数据存在 Cassandra/Scylla”相类比。
- 关于 MySQL 与 Postgres 的讨论：一些人更偏好 MySQL，理由是其在大规模场景下的可靠性和运维熟悉度，并引用了长期经验以及在恶劣条件下的韧性。
- 有人澄清 Meta 使用了多个专门化的 MySQL 层，通常并非纯粹的键值工作负载。
- ZippyDB 和 Async 被描述为长期存在的内部系统；它们本质上并不新，但 Threads 让它们得以被展示出来。
Async 风格系统与替代方案
- Async 被描述为一个用于延迟、非阻塞工作的内部系统（从几秒到数小时）。
- 建议的对应方案包括：SQS + Lambda、带 worker 进程的 RabbitMQ、Google Cloud Tasks、Kafka/Pulsar 加上无服务器框架，或者在较小规模下甚至使用基于数据库的队列。
- 有人指出，流式系统与函数即服务模型之间的融合正在加深。