We mainly use Microsoft technologies when appropriate and others when not. Mostly we develop for Windows operating system.
ASP.NET MVC is our current favourite with CSS and JS to support all the browsers. By default we aim for all browsers released in the past two years including Google Chrome, Mozzila Firefox, Internet Explorer, Opera, Safari and all the mobile versions of these.
Normal web applications are fine or we can use Silverlight for more complex business application clients. Rarely we use desktop technologies with auto update.
Windows Presentation Foundation (WPF) front-end and Windows Communication Foundation (WCF) to connect to the server. We sometimes use 3rd party or own network implementation to meet special needs. Such requirements can be massive amount of data (over 1 MB/s), special security and/or compression or not compatible client and server technologies. Google's Protocol Buffers is a good example to connect CryEngine with .NET server.
We use Windows Service for back-end. Our database of choice is Microsoft SQL Server but we work with Oracle products often. Windows Azure is our most used provider to host servers in the cloud.
We use serveral 3D technologies for games and special multimedia applications. DirectX (C++), CryEngine (C++), SharpDX (C#), XNA and Monogame (C#, Xamarin for iOS and Android). 3D visualization is created with CryEngine's Sandbox editor, Flash UI, and Lua scripts.
We work with big databases in several fields of industry like waste water handling and drinking water cleaning. These process control systems generate data in the range of 100 to 1000 records each second which need to be stored. The yearly amount is well over 10 billion records which need to be accessed to show on charts, to aggregate them for decision making or simply store them for future reference. Data is usually simple (few hundred bytes each record with no foreign keys) but this amount is an issue even for database clusters.
We design and implement such data structures that can handle this amount. This involves compression (down to 1 byte/record) and hierarchical cache systems and can be stored in database server or in file system in a transactional manner. Accessing data with time range select can be done in 10s of milliseconds and a result set of over million records are not a problem.
When all the chart controls give up, we jump in and solve it. Try to find a chart control that can draw a series with millions of points without cheating (using some aggregate function such as average that alter the curve)! Our solution can solve it should you have such amounts of data. You can read more about algorithm in the code corner section.
The same applies to records displayed in datagrid. Built-in controls can solve thousands but what about millions? It is not hard, you need to implement your own drawing algorithms though.
Client-server architecture requires async calling which is supported by most network technologies. We always use this to prevent UI hangs. Some technologies help this or even support only this by default, others do not but can be implemented. We carefully design our lock system on server side to avoid deadlocks and race conditions and protect data.
Parallel programming is done on the GPU with Microsoft AMP C++. We rarely use this technology as it is very hard to design such algorithms that can run parallel but we love it and always keep it in mind as a possible solution.
Another usual security issue is password storing. We store password hashes with salts to counter rainbow attacks on stolen password database.
There are many other areas where security must be considered but we only hightlight one last: SQL injection based attacks. Since we either use Entity Framework or parameterized commands our system is immune to this kind of attacks.
Code quality is important to us. We beleive (others might not) that code length and complexity are correlated to number of bugs. Error-prone-less patterns and everything that helps producing quality code is welcome. We follow some simple rules to never encounter common errors and bugs. We never forget to close a database connection, to free memory, to use critical section to protect data, etc. We try to use such technologies that automatically avoid mistakes (like .net is strong against memory leak but still can do it if you are careless) and/or use patterns to lower risks to the minimum (like try-finally or using blocks for database connection).