sanitize text, clean up bullets and removed colons

README.md

@@ -80,7 +80,9 @@ Which led to the identification of the initial building blocks of the system
 
 ## Quantum Identification
 
-Based on the initial building blocks, we then utilized the quantum concept (https://learning.oreilly.com/library/view/fundamentals-of-software/9781492043447/ch07.html#sec-quantum-def) during our analysis to identify the different parts of the platform that serve different needs and demonstrate possibly different characteristics.
+We considered in our early discussions that there are several parts in the application that should exhibit different characteristics (please see also [below](#system-architecture)).
+
+Based on this observation and the initial building blocks, we utilized the quantum concept (https://learning.oreilly.com/library/view/fundamentals-of-software/9781492043447/ch07.html#sec-quantum-def) during our analysis to identify the different parts of the platform that serve different needs and demonstrate those characteristics.
 
 This the final list along with each quantum responsibilities 
 
@@ -111,7 +113,6 @@ This the final list along with each quantum responsibilities
 
 ## Overall Architecture
 
-
 ### Drivers
 
 #### Key Metrics
@@ -141,35 +142,34 @@ Email parsing, if we consider the 'share your mailbox approach' are much more ch
 
 ### Overall Architecture Characteristics
 
-Given the above we have identified the following top four architecture characteristics:
+Given the above we have identified the following top three architecture characteristics:
 
-* Availability: Since the 
-* Interoperability:
-* Scalability:
-* Configurability:
+* Availability: Since the application must be available to ensure the best customer experience
+* Interoperability: Since we need to interoperate with a lot of travel agents at both national and international level
+* Scalability: Since we both plan to expand and anticipate periods with higher traffic 
+* Configurability: Since this will be an international application with different time zones, currencies, confirmation email languages etc. etc.
 
-We additionally considered 
+Additional applicable characteristics that we considered were:
 
+* Performance especially with regard to external information sources: We decided to address it in the quantum level
+* Deployability: To allow us to quickly onboard new travel agents and reservation types. This will be aided by allowing each quantum to be deployed separately (and possibly in parallel).
+* Fault Tolerance: To allow the system to operate in case of e.g. network issues with external agents / travel systems and/or email providers. We consider that we can address this issue with the CRUD operation provided to the end user as well as the option to parse email updates on top of confirmation emails.
+* Data Consistency: To avoid false notifications to alarm the user or miss important information. Again, we decided to address this issue in the corresponding quanta.
+* Security, we did not identify a specific security requirement (apart from GDPR which we addressed in the analytics quantum) and email sharing which we expect to be standardized.
 
 ### Selected Architecture
 
-Apart from quantum characteristics, the system must also demonstrate characteristics as a whole. We selected the following:
+Based on the characteristics identified, and using the provided template, we came up with the following top matching architectures:
 
-Top:
-Reliability: Because we do not want customers rushing to the airport due to a false alarm
-Scalability: To support future growth
-*Performance*????: To honour the required SLAs despite large number of moving parts with different characteristics
-
-Others considered:
-Security, which we considered as implicit in the solution
+![Architecture Selector](assets/architecture-style-selector.png)
 
-Since we have several quanta with different performance characteristics, and considering the system as a whole, we decided to choose a distributed, event-driven architecture.
+We decided to select the event-driven architecture because it both scores well in most of our characteristics and fits well with asynchronous processing which we think is central to our application. 
 
 TODO: Link to  system wide ADR
 
 [Back to Contents](#contents)
 
-## Quantum Architectures
+## Quanta Architectures
 
 Note: Critical path 5 min - Availability + End to end performance
 We then focused on each quantum and discussed the characteristics that it should demonstrate. Here is what we came up with:

adrs/analytics.md

@@ -2,24 +2,24 @@
 
 The startup is building an analytics platform to support data-driven decision-making. To effectively analyze large volumes of data, we need to select an OLAP (Online Analytical Processing) database. This decision outlines the factors and considerations in selecting an OLAP database for our needs.
 
-## Decision:
+## Decision
 
 We will use a columnar-based OLAP database for our analytics platform that is provided as a managed service
 
-## Pros:
+## Pros
 
 - Scalability: A managed cloud-based solution is designed for high scalability, allowing us to easily accommodate growing volumes of data. This means we can scale up or down as needed without the hassle of managing hardware infrastructure. This scalability ensures our analytics platform can handle future growth in data volume.
 - Performance: Columnar databases excel at query performance for analytical workloads. They store data column-wise rather than row-wise, making it more efficient for aggregations and complex analytical queries. This results in faster query response times, which is crucial for providing a responsive user experience.
 - Integration: A managed service will integrate seamlessly with various data sources and analytics tools, including popular BI tools like Tableau, Looker, and Power BI. This compatibility streamlines the analytics workflow, allowing data analysts and business users to work with their preferred tools.
 - Security and Compliance: Having a managed service will robust security features, including encryption and access control. This is essential for ensuring the confidentiality and integrity of our sensitive data, particularly if we are dealing with personally identifiable information (PII) or sensitive business data. It also helps in meeting compliance requirements such as GDPR or HIPAA.
 - Managed Service: Having a fully managed service, means that we do not focus on routine maintenance tasks such as backups, updates, and scaling. This allows our data engineering and analytics teams to focus on deriving insights from the data rather than managing the infrastructure.
 
-## Cons:
+## Cons
 
 - Cost Overruns: There is a risk of unexpected cost overruns if not managed properly. We will implement cost monitoring and alerts to mitigate this risk.
 - Vendor Lock-in: Choosing a managed service ties us to the vendor. To mitigate vendor lock-in risks, we will design our data architecture in a way that allows for potential future migration to other cloud providers or on-premises infrastructure if necessary.
 
 
-## Justification:
+## Justification
 
 Selecting a managed OLAP database for the analytics platform aligns with our scalability, performance, integration, security, and cost-effectiveness requirements. It is a well-rounded solution that will support our platform's data analytics needs effectively while mitigating potential risks through proper management and architectural design.

adrs/api-gateway.md

@@ -1,28 +1,27 @@
-
 # User Facing API Gateway
 
-## Decision: 
+## Decision
 
-- Establish single entry point for client applications, an API management service that sits between the client app and the collection of the internal services and allow us to make internal changes to our system, completely seamlessly and transparently to our API consumers.
+Establish single entry point for client applications, an API management service that sits between the client app and the collection of the internal services and allow us to make internal changes to our system, completely seamlessly and transparently to our API consumers.
 
-## Pros:
+## Pros
 
 - The API Gateway can abstract and encapsulate our internal APIs offering a single API and implementing a software architectural pattern called *API composition*. The client applications essentially interface one single service API and can execute a single call to the API Gateway, which would then route the request to all the appropriate services and return the response. (workflow, avoids tight coupling)
 - Consolidate all security aspects of the system in one single place. Also, performance benefits due to perhaps implementing SSL termination, and avoiding the overhead of authenticating each request with each service ( security, performance)
 - Improved monitoring since all requests and traffic are handled by API Gateway enhancing our system's observability and traceability capabilities (observability)
 - Protocol translation both for requests handled internally, but also for services exposed externally (e.g. consumption of analytics reports) so as to be flexible to integrate with other systems that may bring us additional revenue. (interoperability)
 
-## Cons:
+## Cons
 
 - API Gateway may become a Single Point of Failure
 - Performance overhead due to another layer of abstraction and routing of requests
 - Require to support and maintain an additional service 
 
-## Justification:
+## Justification
 
 We typically benefit more than we sacrifice in terms of performance, and Single Point of Failure concerns can be mitigated  by deploying multiple instance of the service behind a Load Balancer without incurring significant cost 
 
-## Other Considerations:
+## Other Considerations
 
 We can also break the API Gateway into multiple services e.g. WebAPI gateway, Mobile gateway and third party gateway
 (more specialized and lightweight), but this initially looks like over-engineering and adding development overhead.

adrs/cdn.md

@@ -1,26 +1,25 @@
 # Usage of CDN
 
-## Decision:
+## Decision
 
 CDNs have servers distributed globally, located in strategic places enabling content to be delivered quickly to users regardless 
 of their geographic location. This allows for significant improvement in client's perceived performance. We favor push based
 strategy to upload our content since we do not expect static content to change frequently
 
-
-## Pros:
+## Pros
 
 - CDN caching minimizes the time required to load  assets like images, stylesheets, scripts, resulting in faster page load times. (performance)
 - CDNs can reduce bandwidth costs because they offload a significant portion of traffic from the origin server (cost) while employ efficient compression 
 algorithms on cached content (mobile-friendly)
 - CDNs are designed to handle high traffic loads and can easily scale to accommodate increased demand (scalability)
 
-## Cons:
+## Cons
 
 - Using a CDN service itself comes at a price (cost)
 - Caching can sometimes become an issue leading to outdated content until the cache is purged (complexity)
 - CDN means relinquishing some control over content delivery to a third-party provider.
 
-## Justification:
+## Justification
 
 CDN is a service used in conjuction with our system to improve user experience, lower maintenance costs on our part, and most 
 importantly speed up content delivery to end users that are geographically distributed 

adrs/cqrs.md

@@ -1,6 +1,6 @@
 # CQRS
 
-## Decision:
+## Decision
 
 Command Query Responsibility Segregation (CQRS) is an architectural pattern that separates 
 the read and write sides of an application's data model. This pattern can provide several advantages, 
@@ -9,7 +9,7 @@ but it also introduces complexities and challenges.
 Command Query Responsibility Segregation (CQRS) is an architectural pattern that separates the read and write sides 
 of an application's data model. 
 
-## Pros:
+## Pros
 
 - Optimizing a database with high load of Read and Update operations, by splitting command and query 
 concerns.  This can lead to improved performance and responsiveness, as write operations do not 
@@ -22,7 +22,7 @@ and resource utilization (Scalability)
 allowing for more flexibility in designing the data structures and relationships to meet the specific needs of each 
 side especially for complex or frequently accessed data (extensibility)
 
-## Cons :
+## Cons
 
 - Implementing CQRS introduces additional complexity to the application. Developers need to 
 manage the communication between the read and write sides (complexity). Ensuring data consistency 
@@ -38,7 +38,7 @@ Applying CQRS to a straightforward CRUD application can lead to unnecessary comp
 
 - Increased inherent cost either in terms of hardware or if a cloud provider is used utilization expense (cost)
 
-## Justification:
+## Justification
 
 Concurrent operations to the same records or tables contend with each other making all operations slow. Essentially
 you can optimize a database only for one type of operation at the expense of the other. All write operations that 

adrs/deploy-options.md

@@ -1,25 +1,25 @@
 # Deploy Options
 
-## Decision:
+## Decision
 
 Combining architectural styles of microservices and event-driven apps with containers offers a flexible and efficient approach to developing, 
 deploying, and managing apps for our architectural quanta. Some services which are not core to our system, are stateless and do not 
 require high availability can also be deployed using serverless architecture.
 
-## Pros:
+## Pros
 
 - Containers are lightweight and can be easily scaled up or down to accommodate changing workloads
 - Can be created deployed quickly, and are highly scalable  (either container or serverless apps)
 - Pay-as-you-go model can be cost-effective (serverless apps)
 - Advantages in terms of portability, isolation
 - Can be used as a part of a service mesh since containerized microservices application can be accompanied by a sidecar container that runs the service mesh proxy
 
-## Cons:
+## Cons
 
 - Orchestrating containers in a production environment can be complex familiarity with tools like Kubernetes may be needed
 - Container networking can be complex, especially in scenarios where containers need to communicate with each other or with external services
 
-## Justification:
+## Justification
 
 Containers have become a popular technology for modern application deployment due to their advantages in terms of portability, 
 isolation, and scalability. Adopting best practices, using container orchestration tools, and using them as part of a service mesh

adrs/external-api-integration.md

@@ -1,12 +1,12 @@
 # External API interface integration
 
-## Decision:
+## Decision
 
 Tackle integration scenarios where systems that use different protocols or data formats, should align with your application's architecture and use case, by
 interfacing with external APIs using dedicated components that communicate seamlessly with the system using asynchronous communication mechanisms through
 the usage of message brokers
 
-## Pros:
+## Pros
 
 - Ensures that disparate systems can understand and communicate with each other effectively (interoperability)
 - Enhancing fault tolerance and availability of system since failure to communicate with an external API would not affect the overall
@@ -15,13 +15,13 @@ health of the system (availability, fault tolerance)
 - By offloading integration concerns to different components you can determine the integration method that best suits to each interface 
 using for example different programming languages to build these components (adaptability,interoperability )
 
-## Cons:
+## Cons
 
 - Employing asynchronous communication pattern increase latencies due to indirection (performance)
 - Ensuring the correct ordering and sequencing of messages can be challenging
 - Messages can be duplicated due to network issues or failures
 
-## Justification:
+## Justification
 
 By offloading tasks asynchronously to dedicated components that interface with external APIS, the system can continue 
 being responsive and available without waiting for the completion of the tasks. Also, it promotes loose coupling between 

adrs/gdpr.md

@@ -2,7 +2,7 @@
 
 The service processes personal data as part of our operations. Having an international userbase, we are committed to complying with the General Data Protection Regulation (GDPR) to ensure the privacy and data protection rights of individuals. This decision outlines the architectural considerations and measures to achieve GDPR compliance in our data processing activities.
 
-## Decision:
+## Decision
 
 We will implement a comprehensive set of GDPR compliance measures in our data architecture, including the following key components:
 
@@ -18,10 +18,10 @@ We will implement a comprehensive set of GDPR compliance measures in our data ar
 - Privacy by Design and Default: Privacy considerations will be integrated into our system development processes, following the principles of privacy by design and default. This means that data protection will be considered at every stage of system development.
 - Data Protection Officer (DPO): We will designate a Data Protection Officer responsible for ensuring GDPR compliance and providing guidance on privacy matters within the organization.
 
-## Risks and Mitigations:
+## Risks and Mitigations
 
 - Complexity: Implementing GDPR compliance measures can introduce complexity into our systems. We will mitigate this risk by carefully documenting and automating compliance processes where possible.
 - Resource Requirements: GDPR compliance efforts may require additional resources. We will allocate resources, budget, and training to ensure compliance is achievable and sustainable.
 
-## Conclusion:
+## Conclusion
 Ensuring GDPR compliance in our data processing activities is not only a legal requirement but also a commitment to safeguarding individuals' privacy rights. By incorporating these GDPR compliance measures into our data architecture, we demonstrate our dedication to data protection and privacy, reducing the risk of legal penalties and reputational damage while building trust with our customers and users.

adrs/hybrid.md

@@ -1,23 +1,23 @@
 # Hybrid: Microservices - Event Driven Architecture 
 
-## Decision: 
+## Decision 
 
-- Microservices organizes our business logic as a collection of loosely coupled fine-grained services promoting
+Microservices organizes our business logic as a collection of loosely coupled fine-grained services promoting
 Single Responsibility Principle (SRP), while event driven architecture favors higher scalability by ensuring
 easy decoupling of services by exchanging messages asynchronously and promoting availability and fault tolerance.
 
-## Pros:
+## Pros
 
 - Services can be scaled horizontally easily, adding more instances for targeted services utilizing cost-efficient infrastructure (scalability, elasticity)
 - Better availability, since infrastructure setup can cope with delays on requests and achieve better fault isolation, isolate the problem and mitigate it (availability, fault tolerance, loose coupling)
 - Improving engineering velocity and organizational decoupling, since services can be implemented separately have smaller codebase and also deployed in their own timeline (testability, deployability)
 
-## Cons:
+## Cons
 
 - Microservices introduce complexity in terms of managing multiple services, inter-service communication, and data consistency (performance,data consistency)
 - Combining microservices and event-driven architecture can introduce a significant level of complexity to your system (over-engineering)
 
-## Justification:
+## Justification
 
 Microservices inherently embrace the idea of distributed systems, and event-driven architecture aligns well with the challenges and requirements of distributed systems.
 Event-driven systems allow for asynchronous processing of tasks promoting loose coupling and availability. Also, each microservice can be responsible for specific business functionality therefore it is easier to evolve, modify, or replace individual microservices without affecting the entire system.