Hands-On Software Architecture with Golang

Design and architect highly scalable and robust applications using Go

Jyotiswarup Raiturkar

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781788625104
• Edition: 1
• Topic: Ciencia de la computación
• Subtopic: Programación orientada a objetos

Understand the principles of software architecture with coverage on SOA, distributed and messaging systems, and database modeling

Key Features

• Gain knowledge of architectural approaches on SOA and microservices for architectural decisions
• Explore different architectural patterns for building distributed applications
• Migrate applications written in Java or Python to the Go language

Book Description

Building software requires careful planning and architectural considerations; Golang was developed with a fresh perspective on building next-generation applications on the cloud with distributed and concurrent computing concerns.

Hands-On Software Architecture with Golang starts with a brief introduction to architectural elements, Go, and a case study to demonstrate architectural principles. You'll then move on to look at code-level aspects such as modularity, class design, and constructs specific to Golang and implementation of design patterns. As you make your way through the chapters, you'll explore the core objectives of architecture such as effectively managing complexity, scalability, and reliability of software systems. You'll also work through creating distributed systems and their communication before moving on to modeling and scaling of data. In the concluding chapters, you'll learn to deploy architectures and plan the migration of applications from other languages.

By the end of this book, you will have gained insight into various design and architectural patterns, which will enable you to create robust, scalable architecture using Golang.

What you will learn

• Understand architectural paradigms and deep dive into Microservices
• Design parallelism/concurrency patterns and learn object-oriented design patterns in Go
• Explore API-driven systems architecture with introduction to REST and GraphQL standards
• Build event-driven architectures and make your architectures anti-fragile
• Engineer scalability and learn how to migrate to Go from other languages
• Get to grips with deployment considerations with CICD pipeline, cloud deployments, and so on
• Build an end-to-end e-commerce (travel) application backend in Go

Who this book is for

Hands-On Software Architecture with Golang is for software developers, architects, and CTOs looking to use Go in their software architecture to build enterprise-grade applications. Programming knowledge of Golang is assumed.

Modeling Data

The most valuable asset in today's businesses is data, but data needs to be ingested and structured properly to be of maximum value. This chapter discusses how to model entities, their relationships, and repositories. We will also deep-dive into a few popular data stores, including using them in Golang to demonstrate the principles of data modeling.

In this chapter, we will cover the following topics:

• Entity-relationship modeling
• Engineering various consistency guarantees
• Relational data modeling and a hands-on deep-dive into MySQL
• Key value stores and a hands-on deep-dive into Redis
• Columnar stores and a hands-on deep-dive into Cassandra
• Patterns for scaling data stores

Entities and relationships

During requirements analysis, we identify key objects (things of interest) around which the system is designed. In database parlance, these are called entities. They are objects that are capable of independent existence and that can be uniquely identified. While in object-oriented design the focus is on modeling behavior, entity-relationship modeling is concerned more with attributes and the relationships of entities. In entity-relationship analysis, the relationships are derived from static attributes rather than behavior/interactions, as in the case of object-oriented analysis.

Entities can be usually identified from the nouns in the requirements. For example, in the travel website, a Hotel is a key entity. Requirement analysis gives us insights into the attributes of the entities. For example, the Hotel entity might have the following attributes:

A relationship defines how two entities are related to one another. They can usually be identified from the verbs, linking two or more nouns. For example, a Hotel can have more than one Room, each of which can be reserved at a specific date range—this implies the following relationships:

Diagrams such as the preceding one are called entity-relationship diagrams. It documents and helps to visualize how data is structured in the system.

The entities and the relationships are still at a conceptual level at early stages of requirement. However, as engineering progresses, these get crystallized into storage engine-specific databases, schemas, and other constructs. Also, as our understanding of the domain increases, the initial data design might undergo iterations, including the following:

• Generalization: Formation of entity hierarchies to delineate various related entities
• Normalization: Removing redundancy in the modeled entities (we'll learn about this in detail in the Relational model section)
• Denormalization: Figuring out that redundancy is required and can help in increasing performance in certain use cases (covered in much more detail in the Scaling data section)
• Constraints/business rules: Governance on what values entity attributes can take and the relationships between entities
• Object relational mapper: Mapping of objects in the computation space with the entities persisted in the storage system

Consistency guarantees

Besides modeling entities and their relationships, a key design choice in terms of consistency guarantees that the persistence layer (database) needs to give to the application. If a use case involves modifications of two or more entities, these guarantees from the storage system play a pivotal role in system architecture and SLAs. For example, consider the account transfer use case for a Banking application. After the transfer is done, the net debit/credit amounts should tally—no matter what happens in terms of infrastructure failure. Such logical units of work (debit from account x and credit to account y) are called transactions.

Let's look at some guarantees that databases (and storage systems in general) provide for transactions.

ACID (Atomicity, Consistency, Isolation, Durability)

ACID is a mnemonic for Atomicity, Consistency, Isolation, Durability. It represents one of the most widely supported (and needed!) set of guarantees from storage systems that involve transactions. An ACID-compliant database provides an environment where a high level of consistency can be engineered without complicating the application. This concept is standardized by the ISO (ISO/IEC 10026-1:1992 Section 4). Let's look at each guarantee in detail.

Atomicity

A transaction is atomic if it takes place entirely or doesn't happen at all. In no situation is the database left in a half-modified inconsistent state. The application code can issue read and write operations for a transaction within a session and either commit (make all the changes applicable and visible) or abort (none of the changes are made). Even if the applicable instance or the database instance that was performing the read/write crashes, the transaction stalls and is recovered later on, but never is the atomic constraint violated.

Let's see an example of atomicity. Consider the following simplistic pseudocode, which transfers $100 from account abc to xyz:

amountToTransfer:= 100 beginTransaction() srcValue:= getAccountBalance('abc') srcValue:= srcValue - amountToTransfer dstValue:= getAccountBalance('xyz') dstValue:= dstValue + amountToTransfer commitTransaction() 

If the balances in the abc and xyz accounts were $200 and $300, respectively, then after the transaction commits, the state will be $100 and $400, respectively. If there is a crash or the application encounters an error, the transaction...