Think about RIOTS

🔥 RIOTS!!!🔥 

What do riots have to do with software engineering?

Nothing. 😂 

But it's a handy acronym for thinking about system design.

⬇ Retrieval

➡ Input

⬅ Output

🔄 Transformation

⬆ Storage

The vast majority of software development involves those 5 actions and very little else. If you can break the problem down to those fundamentals, designing and building a solution becomes much easier.

In most apps, you'll be Retrieving⬇ information from a data store. That information becomes Inputs➡ into assorted functions which Transform🔄 the data. The Output⬅ of those functions is the Input➡ for further functions. Finally, the data is Output⬅ either to the screen, a file, or Storage⬆.

This pattern can apply at the class level as well as higher levels. If you follow Uncle Bob's examples of SOLID programming, you'll see how the Output of one function in a class becomes the Input for another (Dependency Injection) with each function applying a single Transformation (Single Responsibility).

---

A common microservice architecture pattern is just RIOTS.

A microservice stores data in its database⬆ (Storage).

Debezium watches for Storage events, takes that event as Input ➡, Transforms it based on your rules🔄, and Outputs⬅ it to a system like Kafka where another microservice can Retrieve ⬇ each entry in the Kafka topic and pass it as Input➡ to a function that Transforms🔄 the data and Stores⬆ it in its own database.

---

RIOTS in the Real World

Let's take a look at a solution from (way back) my history:

The problem: we need to be able to upload VERY large (>1GB) files to Azure Cloud Storage as fast as possible.

The solution: 

Read the file. Break it into small chunks. Store the chunk in a queue to be processed. Inspect each chunk to see if has data or should be discarded. Upload the chunk to the appropriate place if has data.

Reading the file is Retrieval.

Breaking it into chunks takes the stream as Input, transforms part of the stream, and Outputs an object with the chunk of bytes and some metadata.

Storing the chunks in a queue is Storage.

Inspecting the chunks takes the Chunk object as Input and either adds it to the queue to be uploaded (Storage) or discards the chunk (Transformation).

Uploading the chunk is pure Storage and takes a Chunk object as Input.

Ultimately, the utility Output information about the process to the console.

(This predated the current UploadAsync functionality that Microsoft now ships.)