这是一个极具价值的行业案例，闲鱼鱼优惠系统不仅兼顾可扩展、高并发与数据一致性，其设计思路还能为我们带来诸多启发，下面就深入了解这个案例。
个性化系统设计需求
闲鱼为设计个性化优惠券系统需多方思考。因为闲鱼APP用户年轻、多样且社交化。商家针对这些特点营销和优化服务，可提升满意度与转化率。例如根据年轻用户喜好推出潮流商品优惠券，提升购买意愿。
在优惠券设计方面，闲鱼针对粉丝群体提供专门优惠策略，为粉丝购买和回购场景定制定向优惠价，精准定位目标客户，促进交易达成。
海量用户场景难题
闲鱼海量用户场景下，优惠券计算和展示技术难题大。这么多用户同时参与活动，系统压力呈几何级增长。在一些大促期间，优惠券抢购频繁，系统要快速计算并展示优惠信息。
若技术不过关，会出现系统卡顿甚至崩溃。就像线下商场促销人数过多会混乱一样，线上也需应对高并发情况，保证流畅运行。
优惠规则初步架构
为实现优惠设置和计算能力，闲鱼优惠中台有了架构1.0版本。这个版本有一定作用，但也有明显不足。它构建了基本的优惠逻辑框架。 像明确优惠券的类型、适用商品范围等基础内容。
不过，随着业务发展，架构1.0的局限性也显现出来。但当时这个架构让优惠券发放有了基本规则，在一定程度上满足了业务需求。
架构1.0问题凸显
架构1.0在业务规则升级后，可扩展性差。优惠计算要解析【优惠对象】语义判断买家条件，业务规则多了，系统就复杂了。一个店铺业务扩张，增加多种优惠券规则时，系统处理变得困难。
另外，每次优惠查询需长查询过程，性能低下。查询用户关注和购买关系时间长，大流量时系统瘫痪。“双十一”时优惠券查询量大，这种查询方式让系统不堪重负。
架构改进关键思路
为解决架构1.0问题，闲鱼进行改进。发现优惠对象判定可抽象为“用户是否属于某个群体”，于是定义人群概念并提供技术方案。人群充当“协议”和“缓存”，简化判断流程。
这样，优惠计算不再需理解【优惠对象】语义，也不用频繁查询业务系统。比如将经常购买某类商品的用户归为一个人群，优惠计算直接针对人群。
架构2.0数据同步
架构2.0也有问题，重点是业务系统数据同步到人群并保证一致性。交易要求强一致性但访问规模小，团队下单前核对人群同步数据保证实时一致。在一次交易高峰中，通过这种核对避免数据错误。
接入迭代多年的优惠中台，虽从扩展性和性能推演会回到类似架构，但同步人群数据接入仍是挑战。需逐步调整和优化。
你觉得闲鱼这种优惠系统设计思路能否应用到其他电商平台？请点赞和分享本文，并在评论区留言表达你的看法！
