Architecture

What is CQRS?

Bertrand Meyer first introduces the principle of Command Query Separation in his book Object-Oriented Software Construction. The principle states that a well designed object should have methods that are either commands or queries. A command changes the state of an object, but does not return any data, while a query returns data and does not change any state. By dividing methods into these two categories, you will have a better understanding of what does, and what does not, change the state of your system. [Read More]

Ordered Messaging in an Unordered World

At Workiva, we’ve been using NATS to provide a highly-available, scalable message delivery service. The tradeoff for having these properties is that there are restrictions on the order in which messages are received by subscribers. NATS delivers messages from a single publisher in the order in which they were published. However, once you introduce multiple publishers, no such guarantees exist. Furthermore, even if messages are successfully delivered, they may not be successfully processed — if a subscriber fails to process a message correctly when it was sent, it may become out-of-order after retrying. [Read More]

Software Architecture as Business Analysis

Architecture is the bridge between (often abstract) business goals and the final (concrete) resulting system. Software Architecture in Practice A software architect should act as a bridge between business stakeholders and technical stakeholders. To be this bridge requires understanding the business problem being solved, and being able to distill that problem into a technical solution that a software team can implement. In essence, the architect acts as a technical business analyst that helps to define the needs of an organization and recommend solutions that deliver value to stakeholders. [Read More]

Being Good Enough

Better a diamond with a flaw than a pebble without. Confucius We all want to have a perfect product, a perfect system, and a perfect development story. Unfortunately, reality is … reality. And it’s not perfect. One of the biggest struggles of engineering well is understanding the constant push and pull among the forces that govern the “rest of the business”, and governing your technological and development choices accordingly. [Read More]

Creating a Service Oriented Organization

The decision to build products using a service-oriented (or microservice) architecture has enormous technical and organizational impact that is reflected in everything from how teams write code, to how they communicate, to how the organization itself is structured. Given the breadth and depth of impact this decision has, it pays to reflect on why an organization chooses a service oriented architecture, how an organization can support such an architecture, and how teams and individuals can support the organization in successfully adopting a service oriented platform. [Read More]

Integrating Applications: From RPC to Messaging

When integrating two independent services you have two options: making a remote procedure call (RPC), or sending a message. Which should you choose? What is a Remote Procedure Call? An organization often needs to share data and processes between multiple independent processes in a responsive way. For example, updating a user’s name in a shipping system may trigger updates in a billing system. The shipping system could update the billing system’s data directly by modifying a shared database, but this approach requires the shipping system to know far too much about the internal processes of the billing system. [Read More]

Integrating Applications

A big portion of any software engineering revolves around integrating multiple, disparate applications into a cohesive and functional whole. These apps may be built in house or third-party, or they may run on your network or distributed geographically, or they may be microservices designed to integrate. In any of these cases, you have several different options for integration, each with pros and cons. The integration patterns listed here are ordered by least to most sophisticated, but also by least to most complex. [Read More]

The Problem with Point to Point Communication

Point-to-point communication between servers usually works just fine when one or two instances are communicating. One or two instances communicating However, if you increase the number of applications, the total number of connections increases. Three instances communicating In fact, the total number of connections increases as a square of the number of application instances. So, if you are running 100 instances, you will be maintaining O(100^2) connections. [Read More]

Stability Anti-Patterns

I recently finished reading the excellent book “Release It!” by Michael Nygard. One of the key points that I wanted to remember was the stability anti-patterns. So, this post will serve as a reminder of architectural smells to look out for when designing production systems. This list of anti-patterns are common forces that will create or accelerate failures in production systems. Given the nature of distributed systems, avoiding these patterns is not possible. [Read More]

Paper Review: Architecture of a Database System

Title and Author of Paper Architecture of a Database System. Joseph M. Hellerstein, Michael Stonebraker, James Hamilton. Summary Architecture of a Database System provides an explanation of how to implement a relational database. It begins with an architectural overview of the main parts of a database system as viewed through the life of an SQL query. This includes how the query is received, parsed and optimized and how the resulting data is returned from storage as part of a transaction. [Read More]