Head First Architecture Chapter-3

 This chapter is mainly about the fact that software architecture has a lot of tradeoffs.

An Application Scenario:

A scenario was given about an application for selling sneakers (this could be anything tbh), that helps people buy, sell, and trade collectible sneakers. 

The initial architecture was simple a single service that responds to requests send by mobile app users.

So there are 2 options we might get into the tradeoff between them , which are using queues or using topics for messaging :

so we can do the tradeoff analysis for each approach of them:

1- Queue approach  Pros: 
a- It is more secure as the publishing service is aware of the receivers as each new service would have a new queue and the publishing service would need to know about it to send to it.

b- we can have a different format for each receiver.

c- we can scale and monitor independently each queue. 

2- Queue approach Cons:

a- Higher degree of coupling which hurts extensibility.

b- Requires Additional infrastructure for the queues.

c- The publishing service must connect to multiple queues.

3- Topic approach Pros:

 a- Low coupling which helps extensibility. 

 b- Publishing service has only one place to send the message to.

4- Topic approach Cons:

a- Homogenous message for all subscribers.

b- can't monitor or scale a topic independently which hurts scalability.

c- less secure as any service can subscribe to the topic without the publishing service know about it.

So whether we should go with queues or topics , the answer is it depends:
1- if security is paramount then queues.

2- if the application is growing fast and many services would eventually get to integrate with its trading service , then we would go topics.

3- time is also another factor if we need to go to market quickly we might need a simpler architecture.

The key takeaway leads is to the first law of software architecture: 
"Every thing in software architecture is a Tradeoff." 

After debating the pros and cons of a certain point we have to make a decision , as we have dicussed in part 1, architectural decisions are those that affect the structure of the system, examples:

1- We will use cache to reduce the load on the database and improve performance.

2- we will have the reporting service as modular monolith.

3- we will use node.js as the development framework for the MVP.

The idea of doing tradeoff analysis then check the pros and cons of each option available to choose one would lead to the second law of the software architecture:
"Why is more important than How".
This leads us to the need to capture not just the decision but also the reason we made that decision.

Architects use architectural decision records (ADRs) to record such decisions because it gives us a specific template to work with. 

An ADR is a document that describe every architectural decision you made , over time these will build up Architectural decision log.
The chapter then went on to describe in details the structure of the ADR and what each section do in it, I will summarize these in the points below:
1- It needs to have a title that has a 3-digit number as a prefix , upon each new ADR this number is incremented in order to make it easy to know which decisions came before others.
2- Each ADR has a status to express where the team stands on the decision itself.Some of these statuses are RFC (Request for comment ) in case that the ADR is waiting for input from another team or members, Superseded in case that the ADR was superseded by another one , it was advised to have the number of the ADR that supersedes in the status of the ADR, also in the Status of the ADR that supersedes the number of ADR that was superseded (doubly linked ), Accepted as the name suggest in case it was accepted.
3- An Accepted ADR should be immutable , so that we can preserve the chronological sequence of decisions when we trace them at any point , an Accepted ADR can change its status to be superseded as we discussed in the above point.
an example of an ADR that describe the decision of choosing queues vs topics is below:

Title: 012 use of queues for asynchronous messaging between order and down stream services.
Status: Accepted.
Context:
The trading service must inform downstream services (namely the notification and analytics services for now)about all items available for sale and about all transactions, this can be done using synchronous messaging using REST or using asynchronous messaging using queues or topics.
Decision:
we will use queues for asynchronous messaging between the trading and downstream services, using queues make the system extensible as we can have different message for each queue.
Furthermore as the trading service is aware of each and all subscribers, adding a new consumer involves modifying it which improves the security of the system.
Consequences:
Queues means more coupling between the services.
We will need to provision queuing infrastructure, it will require  clustering to provide for higher availability.
If additional downstream services need to be notified we will have to make modifications to the trading service.