DEV Community: Brandon Gautama

Building Software with Clean Architecture

Brandon Gautama — Wed, 04 Sep 2024 06:07:36 +0000

What is software architecture?

It is the shape given to a software system. A software system is made up of individual components. What those components are, how they are arranged and the way they communicate with each other makes up its architecture.

Why clean architecture matters?

The Only Constant is Change! There are two types of values of a software system: functionality (behavior) and architecture (structure). Its functionality value comes from the features it supports, while its architectural value comes from its ability to evolve and adapt to change. That flexibility depends critically on the shape of the system, the arrangement of its components, and the way those components are interconnected.

A clean architecture facilitates the development, deployment, operation, and maintenance of the software system to support its lifecycle. A software system can work perfectly fine today and a good software architecture makes it easy to change if a new requirement comes in tomorrow. It is easy to develop, easy to maintain, and easy to deploy. On the other hand, a messy architecture is very resistant to change.

The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity. If you hold change as a constant, you will learn to adapt and manage its complexities well. Your software should reflect this principle and allow itself to evolve and adapt.

How to build software with clean architecture?

The strategy is to leave as many options open as possible, for as long as possible.

What are the options that we need to leave open? They are the details that don’t matter.

Software systems are made up of two major elements: policy and details. The policy encapsulates all the business rules and procedures. It is where the true value of the system lives. While the details are things that enable humans, other systems, and programmers to communicate with the policy, but do not impact the behavior of the policy. Examples of details are IO devices, databases, web systems, servers, frameworks, communication protocols, etc.

The goal of the architect is to create a shape for the system that recognizes policy as the most essential element of the system while making the details irrelevant to that policy. This allows decisions about those details to be delayed and deferred.

A clean software architecture produces software systems that have the following characteristics:

Independent of frameworks - The architecture does not depend on the existence of some library external libraries/frameworks. They are just tools and you should not force your system to the constraints of the specific frameworks.
Testable - The business rules can be tested without the UI, database, web server, or any other external element that are details.
Independent of the UI - The UI can change easily, without changing the rest of the system. A web UI could be substituted with a console UI without changing the business rules.
Independent of the database - You can swap out Oracle or SQL Server for Mongo, BigTable, CouchDB, etc. Your business rules are not bound to the database.
Independent of any external agency - Your business rules shouldn't know about the interfaces to the outside world.

The concentric circles above represent different areas of software. The further in you go, the higher level the software becomes. The outer circles are mechanisms. The inner circles are policies.

The overriding rule that makes this architecture work is the Dependency Rule: Source code dependencies must point only inward, toward higher-level policies.

Inner circles should never know anything the outer circles. Specifically, the name of something declared in an outer circle must not be mentioned by the code in an inner circle. That includes functions, classes, variables, or any other named software entity.

By the same token, data formats declared in an outer circle should not be used by an inner circle, especially if those formats are generated by a framework in an outer circle. We don’t want anything in an outer circle to impact the inner circles.

1. Entities

Entities are where the enterprise-wide Critical Business Rules lives. They can be used by many different applications in the enterprise, or they can just be the business objects of an application. They encapsulate the most general and high-level rules. They are the least likely to change when something external changes. For example, you would not expect these objects to be affected by a change to page navigation or security. No operational change to any particular application should affect the entity layer.

2. Use Cases

The software in the use cases layer contains application-specific business rules. They orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case.

Any change in this layer should not affect the entities. We do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. However, we do expect that changes to the operation of the application will affect the use cases and, therefore, the software in this layer.

3. Interface Adapters

This layer contains adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external components such as the database or the web. It is this layer, for example, that contain the MVC architecture of a GUI. The presenters, views, and controllers all belong in this layer. The models are likely just data structures that are passed from the controllers to the use cases, and then back from the use cases to the presenters and views.

No code inward of this circle should know anything at all about the database. If the database is a SQL database, then all SQL should be restricted to this layer.

This layer also contain any other adapter necessary to convert data from some external form, such as an external service, to the internal form used by the use cases and entities.

4. Frameworks and Drivers

The outermost layer of the model is generally composed of frameworks and tools such as the database and the web framework. Generally you don’t write much code in this layer, other than glue code that communicates to the next circle inward.

The frameworks and drivers layer is where all the details go. The web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.

Conclusion

Conforming to these rules allow you to build a flexible system. By separating the software into layers and conforming to the Dependency Rule, you will create a system that is intrinsically testable and adaptable.

References: The content of this article is referencing concepts/ideas from the book Clean Architecture by uncle Bob (Robert C. Martin). It is a really great book that I recommend to further if you're interested about software architecture.

Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series). Buy it here: https://amzn.to/3SJguhf

Software Component Design Principles

Brandon Gautama — Thu, 22 Aug 2024 04:56:34 +0000

In my last post, I wrote about SOLID design principles that guides us on how to arrange/create modules from functions and data. Combining these modules together, we get a deployable component. In this article, we will look at some component cohesion principles and component coupling principles.

What is a Component?
Components are units of deployment. They are the smallest entities that can be deployed as part of a system. In Java, they are jar files.

A. Component Cohesion Principles.

Let's take a look at the 3 principles of component cohesion, which gives us guidance on which classes belong in which components.

A1. REP: The Reuse/Release Equivalence Principle
The granule of reuse is the granule of release.

Dependency management tools have become very important due to the vast number of reusable components and component libraries that have been created. Whenever we write a software, it is very likely that we depend on multiple external dependencies.

The Reuse/Release Equivalence Principle states that people who want to reuse software components cannot, and will not, do so unless those components are tracked through a release process and are given release numbers. This is to ensure that all the reused components are compatible with each other and for software developers to know what each new releases will bring.

From a software design and architecture point of view, this principle means that the classes and modules that are formed into a component must belong to a cohesive group and they should be releasable together.

Why is this important? Reusability - Group classes into a component for reusability.

A2. CCP: The Common Closure Principle
Gather into components those classes that change for the same reasons and at the same times. Separate into different components those classes that change at different times and for different reasons.

This is the Single Responsibility Principle restated for components. The CCP gathers together all the classes that are likely to change for the same reasons into the same component. This minimizes the workload related to releasing, revalidating, and redeploying the software.

For most applications, maintainability is more important than reusability. If the code in an application must change, you would rather make those changes in just one component, rather than making changes across many components, so that we only have to redeploy one component.

Why is this important? Developability/Maintainability - Group classes into a component so changes will be done in just one component, thus easier to release.

A3. CRP: The Common Reuse Principle
Don’t force users of a component to depend on things they don’t need.

The CRP states that classes and modules that tend to be reused together belong in the same component. For example, a component contains both the container class and its associated iterators as they are tightly coupled to each other.

The CRP also tells us which classes not to keep together in a component. Every time a dependency component is changed, our component will need to be recompiled, revalidated and redeployed. This is true even if our component doesn’t care about the change made in the used components.

The CRP is the generic version of the ISP. The ISP advises us not to depend on classes that have methods we don’t use. The CRP advises us not to depend on components that have classes we don’t use.

Why is this important? Separate classes into different components to avoid unnecessary releases for our upstream dependencies (since they may not need every change in the component)

Tension between the 3 Component Cohesion Principles:

The three cohesion principles tend to fight with each other. The REP and CCP are inclusive principles (they tend to make components larger), while the CRP is an exclusive principle (driving components to be smaller). It is the tension between these principles that architects seek to resolve.

Balancing these forces with the needs of the application is always dynamic. That is, the partitioning that is appropriate today might not be appropriate next year.

Generally, projects tend to sacrifice reuse (developability is more important than reuse). As the project matures, and other projects begin to draw from it, the project will change focus towards reuse. This means that the component structure of a project can vary with time and maturity.

B. Component Coupling Principles.

Now that we've looked at how to arrange classes into component, let us take a look at how these components should be related to each other, also known as Component Coupling Principles. There are three of them:

B1. ADP: The Acyclic Dependencies Principle
Allow no cycles in the component dependency graph.

To release a component, it must be compatible with its dependencies. It is common to create a new component that depends on a bunch of other dependency components. Those dependency components then depend on more components. Every time any of those dependency component change, there is a risk that it might break the dependent component. This problem is aggravated if there is a cycle in the dependency graph. Releasing a component is much more difficult since it must not break its dependents and those dependents happen to be its dependencies too. Additionally, what is the correct build order? There is no correct answer.

Let's say you have a cycle in the dependency graph, how to fix it? You can apply the Dependency Inversion Principle by inserting interface between those components so they depend on the interface instead.

B2. SDP: The Stable Dependencies Principle
Depend in the direction of stability.

A component is stable if it is hard to change while a component is flexible if it can be changed easily.

What is hard to change? If a change requires multiple dependent components to recompile.

This principle states that we must ensure that the modules that are intended to be easy to change are not depended on by modules that are harder to change. In other words, to keep a component flexible, it should not be depended on by a lot of modules.

For example, DoorDash and Grubhub calls TheRestaurant service. TheRestaurant is stable because it is being depended on by multiple dependents. Any change to TheRestaurant has to ensure it does not break both DoorDash and Grubhub. So TheRestaurant is stable and not flexible. But we want to keep TheRestaurant flexible so that its changeable.

We can fix this by employing the DIP, by creating an interface that DoorDash/Grubhub can call. TheRestaurant itself will implement the interface. These interfaces contains nothing but an interface and this is very common because they are very stable and ideal targets for less stable components to depend on.

B3. SAP: The Stable Abstractions Principle
A component should as abstract as it is stable.

Some software in the system should not change very often. They are high-level architecture and policy decisions. We don’t want these business and architectural decisions to be volatile. But if they are stable, then the source code that represents those policies will be difficult to change and make the overall architecture inflexible. This can be fix using OCP by creating Abstract Classes.

A stable component should be abstract so that its stability does not prevent it from being extended. On the other hand, an unstable component should be concrete since its instability allows the concrete code within it to be easily changed.

Thus, if a component is to be stable, it should consist of interfaces and abstract classes so that it can be extended. Stable components that are extensible are flexible and do not overly constrain the architecture.

Combining SDP and SAP, we can conclude that dependencies run in the direction of abstraction.

Conclusion
In this article, we have explored Component Cohesion Principles and Component Coupling Principles. Component Cohesion Principles gives us guidance on which classes belong in which components, while Component Coupling Principles gives us guidance on how to arrange these components together.

References: The content of this article is referencing concepts/ideas from the book Clean Architecture by uncle Bob (Robert C. Martin). It is a really great book that I recommend to further if you're interested about software architecture.

Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series). Buy it here: https://amzn.to/3SJguhf

The 3 Programming Paradigms
https://dev.to/brandongautama/the-3-programming-paradigms-34pe

The SOLID Design Principles
https://dev.to/brandongautama/the-solid-design-principles-319f

The SOLID Design Principles

Brandon Gautama — Sat, 17 Aug 2024 18:26:01 +0000

In this article, we will explore the SOLID design principles and their architectural implications.

The SOLID design principles guide us on how to arrange our functions and data structures into classes. Now, what if a programming language does not have the concept of a class? A class is simply a coupled grouping of functions and data, so the principles apply to these logical groupings.

These principles enable us to create flexible software modules that tolerate change, are easy to understand and are reusable.

1. SRP: The Single Responsibility Principle

A module should have one, and only one, reason to change.

Note that the principle is not saying that every module should do just one thing, but rather, they have only one reason to 'change'. Software systems are subject to 'change' to satisfy users and stakeholders. In other words, a module should only serve one group of users/stakeholders.

What is a module? The simplest definition is just a source file and this definition suffice for most purposes. A module is just a cohesive set of functions and data structures.

As an example, given Employee class with 2 functions: calculatePay() and reportHours(). This module serves both the Accounting department and HR department. Accounting department only uses calculatePay() while HR department only uses reportHours(). Now, let's say both functions depend on a common method getHoursPerWeek(). If Accounting department wants to tweak getHoursPerWeek(), HR department is forced to consume that change too (even when HR do not want this tweak). This is violating SRP since any change requested by Accounting department may accidentally affect the HR department.

What can we learn from this principle?
Changeability - The SRP says to separate code that supports different users/stakeholders. This will help us create flexible systems that tolerate changes. We can apply this principle at the architectural level to create appropriate architectural boundaries.

2. OCP: The Open-Closed Principle

A software artifact should be open for extension but closed for modifications.

Imagine a system that displays a financial summary on a web page. Now we are asked to print the same information on a paper in a different format.

Clearly, some new code must be written. But how much old code will have to change? Ideally, zero.

How? By properly separating the modules that change for different reasons (the Single Responsibility Principle), and then properly organizing the dependencies between those modules (the Dependency Inversion Principle).

Note that generating the report involves two separate responsibilities: data calculation and data presentation.

We then organize the source code dependencies to ensure that changes to data presentation module do not cause changes in the data calculation module. In this way, we have extended a system to support paper-based format without modifying the current system.

What can we learn from this principle?
Extendability - The idea is to make the system easy to extend without incurring much change to the existing system. This is accomplished by partitioning the system into components, and arranging those components into a dependency hierarchy that protects higher-level components from changes in lower-level components.

3. LSP: The Liskov Substitution Principle

Another way to think of the LSP is the "Plugin Architecture" that polymorphism provides in object-oriented programming. (Read more here)

In this architecture, modules can be substituted for one another as long as they adhere to the same interface.

The world of web is surrounded with interfaces in the form of REST APIs. Consider a food ordering service where a user can order from different restaurants in the same app. Internally, this food ordering service makes a GET call to /order URL. Each restaurant has different implementations for the order but they all expose the same /order URL for the food ordering service to call. Food ordering service do not need to have restaurant-specific logic because of the well-defined interface. This is a good application of LSP where an interface enable substitutions of implementations.

Another example is when we write code to read from STDIN, we are programming to the interface STDIN. STDIN can can be swapped with multiple device drivers implementations.

What can we learn from this principle?
Substitutability - LSP is applicable because there are users who depend on well-defined interfaces, and on the substitutability of the implementations of those interfaces.

4. ISP: The Interface Segregation Principle

The ISP states that we should avoid depending on things that we don’t use.

Going back to the Employee class example with 2 functions: calculatePay() and reportHours(). Let's say both the AccountingDepartment class and HRDepartment class imports and calls the same Employee class. Any change to one of the methods forces both caller to be recompiled and redeployed. Although AccountingDepartment class only uses calculatePay(), it inadvertently depend on reportHours().

This can be fixed by creating 2 interfaces, one for each function and AccountingDepartment only interface with the one containing calculatePay().

What can we learn from this principle?
Avoid unnecessary dependencies to not overcomplicate system.

5. DIP: The Dependency Inversion Principle

The Dependency Inversion Principle (DIP) tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concrete implementations.

In Java, this means that we only import modules that are interfaces or abstract classes.

You might ask, what about String (java.lang.string) class? String class is very stable with rare changes, so we do not have to worry about frequent and capricious changes to String. It is the volatile concrete elements of our system that we want to avoid depending on. Those are the modules that we are actively developing, and that are undergoing frequent change.

Interfaces are less volatile than implementations. Indeed, good software designers and architects work hard to reduce the volatility of interfaces. They try to find ways to add functionality to implementations without making changes to the interfaces. This is Software Design 101.

What can we learn from this principle?
Stable software architectures are those that avoid depending on volatile concretions, and that favor the use of stable abstract interfaces.

Conclusion

Interface! By creating well-defined interfaces that has only one reason to change and programming to those interfaces, it enables us to create appropriate architectural boundaries that allow our systems to change flexibly.

Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series). Buy it here: https://amzn.to/3SJguhf

The 3 Programming Paradigms
https://dev.to/brandongautama/the-3-programming-paradigms-34pe

The 3 Programming Paradigms

Brandon Gautama — Mon, 12 Aug 2024 05:32:38 +0000

In this article, we will explore the 3 programming paradigms and what we can learn from them. As we go through each paradigm, we will see that each tells us what not to do, more than they tell us what to do.

Paradigms are ways of programming that tells you which programming structures to use, and when to use them. There are 3 main paradigms: structured programming, object-oriented programming and functional programming. These paradigms are not programming languages, but rather, programming languages have evolved to cater to the paradigms they target. Java and C++ are examples of object-oriented programming languages, while Lisp and Haskell are examples of functional programming languages.

1. Structured Programming

This is probably the first paradigm that we were taught when we first learned programming. This is also the first paradigm ever to be adopted. It was formalized by Edsger Dijkstra in 1968, where he discovered that all programs can be constructed from just three structures: sequence, selection (if/else) and iteration (do/while).

Structured programming allows modules that used simple selection and iteration control structures to be recursively subdivided into "provable" units over and over, ad infinitum.

Dijkstra once said, “Testing shows the presence, not the absence, of bugs.” A program can be proven incorrect by a test, but it cannot be proven correct. The implications of this fact are stunning. Software development is not a mathematical endeavor, rather, it is science. In Mathematics, we try to prove statements/formulas to be true while in science, we show correctness by not being able to prove its incorrectness.

What can we learn from this paradigm?
Functional Decomposition - structured programming forces us to recursively decompose a program into into smaller functions using divide-and-conquer. We then use tests to try to prove these small provable functions are correct enough for our purposes.

2. Object-oriented Programming (OOP)

What is OO? Encapsulation, inheritance and polymorphism. It provides a way to model the real world by combining data and function using "objects", thus the name object-oriented programming.

In OOP, we use polymorphism extensively along with dependency inversion. They enable us to program to interfaces, rather than specific implementations. This flexibility gives rise to the "plugin architecture" - where specific implementations can be substituted as long as they adhere to the interface contract. As an example, when we write code to read from STDIN, we are programming to the interface STDIN. STDIN can can be swapped with multiple device drivers implementations and the best thing is, our program does not have to change to use the specific implementations (even if they are written in the future).

With this approach, software architects have control over the direction of source code dependencies in the system. They are not constrained to align those dependencies with the flow of control.

What can we learn from this paradigm?
Plugin Architecture - OO provides the ability (through polymorphism) to gain control over source code dependency in the system. It allows architect to create a plugin architecture, where modules containing high-level policies are independent of modules containing low-level details. These modules can then developed and deployed independently from each other.

3. Functional Programming

Functional programming puts emphasis on data immutability. Why does immutability matter? Because race conditions, deadlock and concurrent update problems exist due to mutable variables.

This becomes important as an application scales out, especially in distributed systems, since it will require multiple threads and processors, which can give rise to the concurrency issues above.

Is this practical? Yes, if certain compromises are made. By segregating mutable components from immutable components, we can use disciplines like transactional memory to protect the mutable components from concurrent updates and race conditions. Another way is by keeping track of running transactions instead of mutating values directly, we can calculate the supposedly mutated value from those transactions.

What can we learn from this paradigm?
Immutability - architects should design systems that is robust in the distributed world which require multiple threads and processors.

Conclusion

What do these programming paradigms teach us about software architecture?

Functional Decomposition - structured programming is the algorithmic foundation of our modules
Plugin Architecture - polymorphism is the mechanism to cross architectural boundaries while ensuring separation of components
Immutability - impose discipline on the location and access of data

Buy it here: https://amzn.to/3SJguhf

Exploring React JS. Where to Start?

Brandon Gautama — Mon, 29 Jul 2024 21:50:34 +0000

Hearing React almost everywhere, I can't help but to explore it too! Although I don't need React as a backend engineer, I feel it could be a great way to get exposure to the front-end world and help me understand the big picture (it did!). I get to learn the perspectives/challenges of front-end development, and keep them in mind when designing back-end systems. More importantly, its just satisfying to learn how things work end-to-end.

But where to start?

If you have basic knowledge of JavaScript, here are (free!) resources that I would recommend:

1. Learn React by Scrimba (https://v2.scrimba.com/learn-react-c0e)
A really great resource to start writing React.

Learning a new technology is not easy. Given the amount of abstractions we see these days, sometimes it can get frustrating to ignore stuffs you don't really understand and told to just accept that it works. (Questions like "What is going on behind the scenes in this line of code?")

The instructor at Scrimba did great at explaining what every line of React code means, leaving no mysteries behind. He explained the motivation behind choosing React by showing what a line in React means in Vanilla JS. It really clears a lot of doubts and terms, especially when you first start to learn a new technology.

2. Full Stack Open (https://fullstackopen.com/en/)
An awesome resource that I can't recommend enough. Note that this course is not just about React, but it gives you an 'end-to-end' experience of developing a full-stack software using React for front-end. Even though it's not a React-only course, the React part is very comprehensive (covering even Redux). You can choose to only learn the React part of the course but I would really recommend completing the whole thing.

Here are why I really liked the course:

Full picture

It first goes into the Fundamental of web applications before introducing React as the front-end and NodeJS as the back-end for creating REST APIs. It then gives you a feel of how testing works in the web. It then helps you setup a deployment pipeline using Github Actions (CI/CD) and helps you familiarize with Docker containerization. It goes all the way from developing to deploying both front and back-end application to production.

Industry standard

I am a backend software engineer myself and I can relate to how much the course prepares you to work in the industry. It touches on a lot of aspects that makes a projects more realistic. For example, unit testing front and back-end, integration testing and end-to-end testing. These testings are very valuable in an actual production projects and yet, a lot of online classes missed them. It teaches you how to setup a CI/CD pipeline, manage configs separately for security reasons, containerize your applications, etc. There are a lot of best practices in this course!

Practice!

Each module comes with its own set of exercises and I highly recommend that you complete those exercises. Learn programming by doing - only then the concepts, syntax and ideas can materialize in your mind. I always believed that the best way to learn is to practice it!

"Modern and up-to-date"

Besides the fact that it is teaching React (one of the most popular front-end framework used in the industry), it also teaches NodeJS (another popular back-end framework) and uses Github Actions (for CI/CD) and Docker (containerization). In addition, this course is actively maintained and revised (you can see sections of the course that says its updated because of the ever-changing nature of software).

Message Delivery System using AWS Step Functions

Brandon Gautama — Sat, 20 Jul 2024 06:23:11 +0000

Background

My team owns a cloud microservice that orchestrates the collection of content from other microservices and delivers them to customer-facing devices.

Problem

Recently, I was tasked to design a cloud system that can ensure delivery of a given message to any target device. A delivery is successful if the target device sends back an ACK (acknowledgement) response.

Normally, this would be an easy task. If the message is dropped in the communication channel or if the target device is offline or behaving incorrectly, the service can just retry until it receives the ACK. Since most programming languages (e.g. Java's built-in HttpClient) supports this out of the box, this retry system can be easily built.

However, this is only true for synchronous communications where a client opens a connection channel, sends a request and awaits a response through the same channel. If there is no response in that channel or a bad response was received in that channel, the service knows that it has to retry. Things get complicated in an asynchronous system, where the response comes back through a different channel than where the request was sent. (How to schedule the next attempt?)

In addition, the retry has to be attempted with backoffs up to 'seconds' precision. That is, after the first attempt, wait for 15 seconds before the second attempt, then wait for 30 seconds before the third attempt, then additional attempts has to wait for 4 hours.

Design

Given the above requirements, we know we needed a scheduler.

Something similar to CronJob would work so we looked for AWS products that can simulate this 'scheduling' behavior.

We first looked at AWS EventBridge Scheduler but it could only support up to the 'minute' precision, while we needed something with 'seconds' accuracy.

We then came across AWS SQS. SQS has a feature called 'message delay' where a message in the queue is only visible after the delayed time set in seconds. So we took advantage of that delay as a way to schedule the next retry. Here is how it works:

The first attempt to deliver the message to device is accompanied with a message to the 15-seconds queue.
When the message from 15-seconds queue becomes visible (after 15 seconds), we first check whether the message has been ACKed. If it hasn't been ACKed, attempt another message delivery to device while at the same time, enqueue the message into the 30-seconds delay queue. If it has been ACKed, the process stops here.
When the message from 30-seconds queue becomes visible (after 30 seconds), we first check whether the message has been ACKed. If it hasn't been ACKed, attempt another message delivery to device while at the same time, enqueue the message into the 4-hours delay queue. If it has been ACKed, the process stops here.
The above repeats until we received the ACK.

Although the above works, note that for every message, there is always one extra traffic. For example, if the message was ACKed at the first attempt, no retry is needed. Yet, the message is already enqueued into the 15-seconds delay queue and when the message becomes visible, we check that the message has been ACKed and therefore, we do not attempt another delivery to device. That is wasted traffic. It felt like SQS may not be the right solution. We were repurposing SQS to force-fix our problem with its 'message delay' feature and its 'seconds' precision. So we decided to keep looking for better alternatives.

At that time, we recognized that the scheduler has this notion of 'states'. It is behaving differently based on different states, i.e. second attempt has to wait for 15 seconds while third attempt has to wait for 30 seconds. Depending on the number of attempts made, the scheduler has to set different delay values. Thats when we realized the problem can be generalized as a Finite State Machine (FSM). Step Functions to the rescue!

Here is how it works:

The machine starts with first message delivery using API Gateway: Invoke
The machine then goes into a 'Wait' state of 15-seconds
After 15-seconds timer is up, the machine proceeds to the 'Choice' state and check whether message has been ACKed. If yes, then the machine goes to 'End' state. Else, the machine attempts another message delivery by going back to the API Gateway: Invoke step above.
Step 2 and 3 repeats with 30-seconds timer
Step 2 and 3 repeats with 4-hours timer

Note that we can simplify this further. If we add an additional behavior when we receive the ACK from device to stop this step function execution, we can remove the 'Choice' state. In other words, this execution only exists if we have not received the ACK.

Summary

AWS Step Functions is a workflow orchestration system. It can be a very powerful tool, especially when solving problems related to scheduling and state machines workflows.

It can be used to support both event-driven and schedule-based architectures. Its SDK Integrations to other AWS Services eases development especially if you're already building on AWS infrastructure.

I encourage you to check their official documentation. (Surprisingly?) they can be used to solve a lot of design problems!
AWS Step Functions