Design Patterns: Queue-Based Load Leveling Pattern

Modern software usually involves running tasks that invoke services. If the service is subjected to intermittent heavy loads, it can cause performance or reliability issues. If the same service is utilized by a number of tasks running concurrently, it can be difficult to predict the volume of requests to which the service might be subjected at any given point in time.

It is possible that a service might experience peaks in demand that cause it to become overloaded and unable to respond to requests in a timely manner. Flooding a service with a large number of concurrent requests may also result in the service failing if it is unable to handle the contention that these requests could cause.

The Asynchronous Queue

By introducing an Asynchronous Queue between a task and a service, you will be decoupling the task from the serviceThe service will be able to handle the messages at its own pace, irrespective of the volume of requests from concurrent tasks.

Using a Queue

The queue acts as a buffer, storing the message until it is retrieved by the service. The service retrieves the messages from the queue and processes them.

Requests from a number of different tasks, which can be generated at a highly variable rate, can be passed to the service through the same message queue and will be processed at a constant rate that the service can work at.


  • Maximizing Availability: Delays or Downtime of the service does not affect the application generating the messages
  • Maximizing Scalability: Number of Queues and Services can be varied to meet Demand. In a later blog post, I discussed the Competing Consumer Pattern, which helps in scaling your applications by running multiple instances of a service, each of which act as a message consumer from the load-leveling queue.
  • Control Costs: You don’t have to design your service to meet peak load, but rather average load


The biggest consideration to keep it mind when implementing the Queue-Based Load Leveling Pattern is that an Asynchronous Queue is a one-way communication mechanism! If a task expects a reply from a service, it may be necessary to implement a mechanism that the service can use to send a response.

Message Brokers

Message Brokers are servers that take care of Queue Handling, Routing Messages, High Availability and Scaling out. There are many different message brokers and discussing which is best in which scenario would take a whole blog post, but a few famous ones are:

  • RabbitMQ – Popular, Reliable, Excellent Documentation, Easy to Install, Configure and Use, Clutering, High Availability, Multi-Protocol, Runs on all major Operating Systems, Supports a huge number of developer platforms, Written in Erlang
  • Azure Service Bus – The Go-To choice if you’re already on Azure, High Throughput, Predictable Performance, Predictable Pricing, Secure, Scalable on Demand
  • Apache Kafka – High-Throughput, Low-Latency, Uses Apache ZooKeeper for Distribution, Written in Scala and Java
  • Amazon Simple Queue Service – The Go-To choice if you’re already on AWS, Reliable, Simple, Flexible, Scalable, Secure, Inexpensive

A choice of Message Broker requires careful consideration as each has their pros and cons.





Sql Server, Create Temp Table

-- drop table #tmp_palnets
IF OBJECT_ID('tempdb..#tmp_palnets') IS NOT NULL DROP TABLE #tmp_palnets
print('DROP TABLE #tmp_palnets')
-- create temp table
create table #tmp_palnets  (NR_ORDER int,NR_DISTANCE int,NM_COLOR nvarchar(50), NM_NAME nvarchar(50))

-- populate table
insert into #tmp_palnets values (1	,2985	,'BLUE'		,'earth')
insert into #tmp_palnets values (2	,135	,'RED'		,'mars')
insert into #tmp_palnets values (3	,128741	,'GRAY'		,'pluto')

-- select temp data
select * from #tmp_palnets<span data-mce-type="bookmark" id="mce_SELREST_start" data-mce-style="overflow:hidden;line-height:0" style="overflow:hidden;line-height:0;">&#65279;</span>




Migrations Commands

View Script: Update-Database -Script -SourceMigration:0


Enables Code First Migrations in a project.

Enable-Migrations [-ContextTypeName ] [-EnableAutomaticMigrations]
[-MigrationsDirectory ] [-ProjectName ] [-StartUpProjectName ]
[-ContextProjectName ] [-ConnectionStringName ] [-Force]
[-ContextAssemblyName ] [-AppDomainBaseDirectory ] []

Enable-Migrations [-ContextTypeName ] [-EnableAutomaticMigrations]
[-MigrationsDirectory ] [-ProjectName ] [-StartUpProjectName ]
[-ContextProjectName ] -ConnectionString
-ConnectionProviderName [-Force] [-ContextAssemblyName ]
[-AppDomainBaseDirectory ] []
Enables Migrations by scaffolding a migrations configuration class in the project. If the target database was created by an initializer, an initial migration will be created (unless automatic migrations are enabled via the EnableAutomaticMigrations parameter).


Scaffolds a migration script for any pending model changes.

Add-Migration [-Name] [-Force] [-ProjectName ] [-StartUpProjectName ]
[-ConfigurationTypeName ] [-ConnectionStringName ] [-IgnoreChanges]
[-AppDomainBaseDirectory ] []

Add-Migration [-Name] [-Force] [-ProjectName ] [-StartUpProjectName ]
[-ConfigurationTypeName ] -ConnectionString -ConnectionProviderName
[-IgnoreChanges] [-AppDomainBaseDirectory ] []


Applies any pending migrations to the database.

Update-Database [-SourceMigration ] [-TargetMigration ] [-Script] [-Force]
[-ProjectName ] [-StartUpProjectName ] [-ConfigurationTypeName ]
[-ConnectionStringName ] [-AppDomainBaseDirectory ] []

Update-Database [-SourceMigration ] [-TargetMigration ] [-Script] [-Force]
[-ProjectName ] [-StartUpProjectName ] [-ConfigurationTypeName ]
-ConnectionString -ConnectionProviderName
[-AppDomainBaseDirectory ] []
Updates the database to the current model by applying pending migrations.

Only valid with -Script. Specifies the name of a particular migration to use as the update’s starting point. If ommitted, the last applied migration in the database will be used.

Specifies the name of a particular migration to update the database to. If ommitted, the current model will be used.

Generate a SQL script rather than executing the pending changes directly.

Specifies that data loss is acceptable during automatic migration of the database.

Specifies the project that contains the migration configuration type to be used. If ommitted, the default project selected in package manager console is used.

Specifies the configuration file to use for named connection strings. If omitted, the specified project’s configuration file is used.

Specifies the migrations configuration to use. If omitted, migrations will attempt to locate a single migrations configuration type in the target project.

Specifies the name of a connection string to use from the application’s configuration file.

Specifies the the connection string to use. If omitted, the context’s default connection will be used.

Specifies the provider invariant name of the connection string.

Specifies the directory to use for the app-domain that is used for running Migrations code such that the app-domain is able to find all required assemblies. This is an advanced option that should only be needed if the solution contains several projects such that the assemblies needed for the context and configuration are not all referenced from either the project containing the context or the project containing the migrations.