投票活动的承载难点，通常不在日常访问，而在截止前集中涌入的投票请求和榜单查询。架构设计不能只看参与人数，也要区分“同时在线”与“同一时刻发起请求”：用户停留在页面，不等于持续产生请求；反过来，集中刷新榜单也可能与投票写入争抢资源。
承载设计应先把业务路径拆开。投票提交需要完成身份与规则校验，并可靠记录票数；榜单查询则要快速返回排名和统计结果。两类负载的目标不同：投票侧优先保证数据准确、不重复计票，查询侧优先控制响应压力。若所有请求都直接落到数据库，高峰期写入和频繁读取容易相互影响。可结合缓存、数据库优化与负载均衡分担压力；当活动规模和持续运营需求更高时，再评估分布式架构，而不是为了“高并发”一开始就堆复杂度。
缓存不能代替真实计票。榜单允许短暂延迟时，可以减少高频查询对数据库的冲击；但最终结果仍应以可靠的投票记录为准，并明确统计更新规则。若页面显示与最终票数存在延迟，应在产品侧说明，避免把正常的榜单刷新间隔误认为数据丢失。
容量评估要围绕真实峰值场景，而不是只按总报名人数估算。需要梳理投票是否集中在短时段、榜单刷新频率、报名与投票是否同时开放，以及活动截止时是否会出现流量突增。上线前应针对这些路径做压力测试，观察系统在高负载下是否出现响应变慢、投票失败或统计不一致，并据此调整资源与架构。测试结果也应成为承载承诺的依据，不能仅凭“支持高并发”的描述判断方案可靠。
最后，防刷与承载需要协同设计。验证码、身份校验等风控会增加请求处理环节，过于简单的限制可能拦不住异常流量，过重的校验也可能拖慢正常用户投票。较稳妥的做法是先确定结果公正性要求和预期峰值，再选择匹配的风控强度，并把投票提交、榜单查询和异常流量分别纳入测试。架构承载的目标不是追求复杂，而是在高峰时仍能可靠计票、稳定展示。
