在郑州一家制造企业做私域系统时，我先被一个现实问题拦住脚：线索、会员、销售在不同表里游离，客户触达靠人工，留存和转化指标上不去。于是决定把客户管理和营销裂变合并为一套可编排、可追踪的私域运营系统，目标既要保证数据一致性，也要支持实时投放与裂变闭环。

      技术栈定型后做了取舍：微服务用Spring Boot + gRPC做同步调用，事件流用Kafka，主库选MySQL，搜索用Elasticsearch，实时特征计算用Flink，在线服务缓存落到Redis。身份体系靠微信unionId作为主键，辅助手机号做二次校验；OAuth、消息签名与回调校验放在网关层统一处理。我常说，设计出事件边界比选框架更重要；这点在拆分客户生命周期事件时尤其明显。

      裂变模块不是单发券那么简单。核心是：如何防止重复奖励、如何追踪传播链路、如何在高并发下维持一致性。实操上用短链+campaignId跟踪入口，服务端对每个campaign生成唯一idempotency-key并在Redis用SETNX去重，发券写入时再靠数据库唯一索引兜底。为了避免被刷量，加入布隆过滤器快速判断是否曾领取；遇到误判，用补偿任务定期扫表纠正。

      排查问题的套路带着工具味儿：遇到微信回调重复、模板消息延迟，我会先用ngrok复现回调，再靠kafkacat查看topic滞留量，用Jaeger回溯分布式调用链，最后在数据库层看唯一索引冲突日志。曾因并发写导致券重复发放，定位到是异步消费者重试与业务侧无幂等检查共同作用，修复思路是加幂等键、消费位点可见化并把重试策略从无限制改为线性退避。

      运维与演进上，我倾向于小步迭代：用Kubernetes + Helm做部署，借Istio做流量熔断与金丝雀发布，Prometheus+Grafana监控SLA和留存路径。建议把复杂个性化推荐放离线预算，在线以Redis特征表提供低延迟决策。最后一点：裂变是增长杠杆，但更依赖工程的可靠性；把防刷、防重复、回溯能力当作首要工程指标来做，会比单纯追新功能更稳妥。