Brick Model and User Data Replication

Another welcome change in Lync Server 2013 is the addition of the Brick Model within Front End pools. One of the investments made was to reduce the dependency on the backend SQL server database’s availability so that users should be unaware if database issues are occurring. The Brick Model moves more functionality into each Front End Server, which now manages the user’s presence states directly. Changes to the backend database are done only for persistent data and are considered lazy writes, so a temporary issue at the database doesn’t have a high impact on users.

Users are now automatically partitioned into objects called UserGroups within a Front End pool, similar to how each user had a preferred server order for a Lync Server 2010 pool. Each UserGroup is then assigned up to three Front End Servers within a pool, so there are up to three copies of the user’s data stored directly on the pool members. If a UserGroup’s primary Front End Server fails, the secondary or tertiary can immediately begin servicing that UserGroup because they already have the data stored.

These Brick Model changes also allow pools to scale out to larger numbers. Twelve Front End Servers can be deployed within a single Lync Server 2013 pool, up from only 10 in Lync Server 2010. This still only allows a single pool to now support up to 80,000 concurrent users, but allows for full operating capacity even after two Front End server failures.