SNS类型的游戏和RPG类的网游有一些不同的特点，而这些特点会导致这类游戏的后台架构和RPG网游的后台架构存在一些区别。
SNS类型的游戏一般有以下的特点：
（1）所有的玩家角色可能存在交互
SNS类型的游戏一个玩家角色会找他的好友或者其他任何一个毫无关系的玩家角色进行某种逻辑上的互动。
（2）这类游戏玩家角色一般是看不见的
（3）玩家角色在线或离线状态比较模糊
在线的玩家角色可以主动找不在线玩家进行交互。如去某个没上线的好友菜园偷菜，去攻打不在线的玩家角色的城池。
（4）交互频率较低，数据量小。
根据上面的主要特点，这类游戏后台要设计成唯一一个的大世界，而角色之间无须相互可见，实现这个大世界后台就有存在的可能。实际的商业项目中，可以采用下面的架构。
一般前面的节点往后主动连接。
connsvr有可能是webserver，也有可能是自定义协议的tcpsvr；他采用某种hash映射的方式，将client(网页或桌面程序)请求的消息包转发给任意一个schedulesvr。
schedulesvr收到某个消息请求，根据请求的业务特点，将请求分发给一个或多个logicsvr；同时他可能会提供事物机制，保证请求处理的完整性。
logicsvr和上面转发hash映射机制对应的方式的作分布式部署。
dbproxy是访问DBMS的代理。
另外说明一下，服务器之间建议用tcp通信，这样可以借助tcp拥塞控制的机制做应用层的流量控制。
举个简单例子，来说明一下某个游戏逻辑的流程。就拿偷菜来说，client1上的玩家A想偷好友B的菜。
（1）A根据某种负载均衡机制（DNS轮询就可以了）向某个connsvr发请求包，connsvr将请求包转发给某台schedulesvr；到A所在的logicsvr上。
（2）schedulesvr发请求给A所在的logicsvr，这个logicsvr做一些基本验证，如B是否是A的好友等，处理偷菜逻辑；如果B也在这台logicsvr上，那就直接处理B的被偷逻辑；最后把结果返回给schedulesvr。（3）schedulesvr发现A&B不在一个logicsvr上，如果（2）的逻辑处理成功，将消息再转给B所在的logicsvr，logicsvr把B的菜数量减掉。
（4）schedulesvr最后收到B的处理的结果，把回应返回给Client。
上面是一个比较简单的sns应用，只涉及到双方。最简单的应用是只涉及自己。另外，有些sns会和3方或更多方扯上关系，这个可以考虑用类似schedulesvr性质的服务器处理这类业务。像大部分SNS类型的游戏会附加很多小游戏，就上面类似的方法处理。像邀请一些好友一起做某种游戏之类的小游戏可以考虑用独立的进程处理。
小游戏logicsvr和下面的logicsvr有本质的不同，前者只须局部的玩家角色数据，而后者的数据要求是全局性的。
小游戏的游戏结结果往往要在主游戏中较及时的反映出来，比如得到某些物品，经验级别有变化了之类。大体流程一般这样：
（1）多个角色进入到小游戏中时，要从各自的主logicsvr中拉取最新数据。
（2）小游戏完成后，要将游戏结果（一般是增量）保存到各自的主logicsvr，再退出，返回到主logicsvr。