Design Patterns and Methodologies

The 12-factor methodology is a set of best practices for building software-as-a-service (SaaS) applications that run in the cloud. It was introduced by Heroku, a cloud platform for building, deploying, and scaling web applications. The 12 factors are:

1. Codebase: A single codebase for the entire application, with multiple deploys.

2. Dependencies: Declare and isolate dependencies through a dependency declaration manifest.

3. Config: Store configuration data in the environment, not in the code.

4. Backing Services: Treat backing services as attached resources, such as databases or message queues.

5. Build, Release, Run: Automate the build, release, and run stages to ensure consistent deployment.

6. Processes: Execute the application as one or more stateless processes.

7. Port Binding: Export services via port binding, not via a shared database.

8. Concurrency: Scale out by adding processes, not by cloning existing ones.

9. Disposability: Maximize robustness with fast startup and graceful shutdown.

10. Dev/Prod Parity: Keep development, staging, and production as similar as possible.

11. Logs: Treat logs as event streams.

12. Admin Processes: Run administrative and management tasks as one-off processes.

By following these principles, developers can build scalable, maintainable, and robust cloud-based applications that are easy to manage and deploy. The 12-factor methodology has become a popular reference for building SaaS applications, and is widely adopted by companies such as Netflix, Slack, and Airbnb.

Here are some real-world examples of applications that follow the 12-factor methodology:

1. Heroku: Heroku is a popular cloud platform that provides a platform for building, deploying, and scaling web applications. It follows the 12-factor methodology by using environment variables to store configuration, using backing services such as databases and queues, and by having a stateless design that makes it easy to scale horizontally.

2. Netflix: Netflix is a streaming video service that uses the 12-factor methodology to build and operate its cloud-based applications. It uses services such as AWS for its infrastructure and storage, and its applications are designed to be stateless and scalable, making it easy to manage and maintain its large-scale, global operations.

3. Slack: Slack is a popular team collaboration platform that uses the 12-factor methodology to build and operate its applications. It uses environment variables for configuration, and its architecture is designed to be stateless and scalable, making it easy to manage and maintain its operations.

4. Airbnb: Airbnb is a popular vacation rental platform that uses the 12-factor methodology to build and operate its applications. It uses cloud-based infrastructure, such as Amazon Web Services, to run its applications, and its architecture is designed to be stateless and scalable, making it easy to manage and maintain its operations.

5. Stripe: Stripe is a payment processing platform that uses the 12-factor methodology to build and operate its applications. It uses environment variables for configuration, and its architecture is designed to be stateless and scalable, making it easy to manage and maintain its operations.

Examples of applications that can be designed using the 12-factor methodology include:

1. E-commerce websites

2. Social media platforms

3. Collaboration tools

4. Project management software

5. Customer relationship management (CRM) systems

6. Human resources management systems

7. Accounting and financial management systems

8. Supply chain management systems

9. Inventory management systems

10. Marketing automation tools

11. Healthcare management systems

12. Learning management systems

Here is a sample architecture for a 12-factor application:

1. Codebase: The entire application code is stored in a version control system, such as Git, and multiple deploys can be made from this single codebase.

2. Dependencies: The application dependencies are declared in a file, such as a Maven pom.xml file, and isolated from the application through a dependency declaration manifest.

3. Config: Configuration data, such as database connection strings or API keys, are stored in environment variables and are not part of the application code.

4. Backing Services: Backing services, such as databases or message queues, are treated as attached resources and accessed through APIs or service discovery mechanisms.

5. Build, Release, Run: The build, release, and run stages are automated through a continuous integration and continuous deployment (CI/CD) pipeline, using tools such as Jenkins or TravisCI.

6. Processes: The application is executed as one or more stateless processes, which can be scaled horizontally by adding more instances of the process.

7. Port Binding: Services are exported via port binding, rather than through a shared database or other mechanism, allowing for easier scaling and load balancing.

8. Concurrency: The application is designed to scale out by adding more processes, rather than by cloning existing ones.

9. Disposability: The application is designed to be highly disposable, with fast startup and graceful shutdown, to maximize robustness and reduce downtime.

10. Dev/Prod Parity: Development, staging, and production environments are kept as similar as possible, with the same tools, processes, and dependencies, to reduce the risk of environment-specific bugs.

11. Logs: Logs are treated as event streams, with log data emitted to a centralized log management system, such as Logstash or Fluentd, for analysis and troubleshooting.

12. Admin Processes: Administrative and management tasks are executed as one-off processes, rather than being part of the main application, to ensure separation of responsibilities and to allow for easy maintenance and management.

Here are some of the best design patterns to build modern applications:

1. Model-View-Controller (MVC): A pattern that separates the application into three components: the model, which represents the data; the view, which is responsible for presenting the data; and the controller, which manages the interaction between the model and the view.

2. Microservices: A pattern that decomposes a monolithic application into a set of smaller, independent services, which can be developed, deployed, and scaled independently.

3. Command Query Responsibility Segregation (CQRS): A pattern that separates the responsibility for writing data from the responsibility for reading data, enabling better scalability and performance

4. Domain-Driven Design (DDD): A design pattern that focuses on modeling the business domain, using concepts such as entities, services, value objects, and aggregates to create a rich, expressive model that can capture the complexity of the business domain.

5. Event Sourcing: A pattern that uses a log of events to store the state of the application, rather than a traditional database, to provide a full history of the changes to the application state.

6. Serverless: A pattern that uses cloud-based functions to execute code, without the need to manage the underlying infrastructure, to provide cost-effective and scalable computing.

7. Reactive: A pattern that enables applications to respond to changing conditions and handle large amounts of data and concurrency, using reactive programming techniques.

8. Decorator: A pattern that provides a flexible way to extend the functionality of an object, without modifying its code, by using wrapper classes to add or override behaviour.

9. Singleton: A pattern that ensures that a class has only one instance, and provides a global point of access to that instance, to simplify resource management.

10. Factory Method: A pattern that creates objects without specifying the exact class of object that will be created, allowing for greater flexibility and modularity.

11. Dependency Injection: A pattern that separates the construction of objects from their behavior, allowing for greater flexibility, testability, and maintainability

12. Observer: A pattern that allows objects to receive notifications of changes in the state of other objects, allowing for loosely coupled, event-driven systems.

Saga Design Principle

The Saga design principle is a pattern used in microservices architecture to handle long-running transactions that involve multiple microservices and is a way to handle distributed transactions in a microservices architecture. It provides a mechanism for coordinating and managing the lifecycle of a transaction across multiple microservices. which. means consistency and reliability in a distributed system by breaking down a complex transaction into a series of smaller, independent steps.

The basic idea behind the Saga pattern is that each step in a transaction is represented by a separate microservice, and each microservice implements a compensating transaction that can undo the effects of the transaction if it fails(the sequence of local transactions, each of which updates the state of a single service. If a step fails, the Saga records the failure and compensating transactions are executed to undo the changes made by previous steps and bring the system back to its original state).

This allows transactions to be automatically rolled back in the event of a failure, which helps to ensure consistency and maintain data integrity.

Sagas provide a number of benefits, including:

• Atomic transactions: Sagas ensure that a transaction is either fully completed or fully rolled back, even in a distributed system.

• Resilience: Sagas can handle failures and network partitions, ensuring that the system remains consistent even in the face of failures.

• Loose coupling: Sagas promote loose coupling between microservices by allowing each service to focus on its own local transactions, while the Saga coordinates the overall transaction.

• Flexibility: Sagas can be easily extended or modified, making it easy to add new steps or compensating transactions as the system evolves.

The Saga design principle is an important tool for designing and implementing distributed systems, and is widely used in microservices architecture to handle complex and long-running transactions in a reliable and scalable manner.

The key principles of the Saga design pattern are:

1. Saga execution: The Saga is executed as a sequence of transactions, each represented by a separate microservice.

2. Compensating transactions: Each transaction in the Saga has a compensating transaction that can undo the effects of the transaction if it fails.

3. Coordination: The Saga coordinator manages the lifecycle of the Saga and ensures that the compensating transactions are executed if a failure occurs.

4. State management: The Saga coordinator maintains the state of the Saga, including the state of each transaction in the Saga.

5. Idempotency: Each transaction in the Saga must be idempotent, so that it can be executed multiple times without causing any side effects.

The choreography-based approach to implementing the Saga design pattern is a decentralized mechanism, where each local transaction is executed as an independent service and communicates with other services through messages or events. If a transaction fails, it sends a compensation message or event to trigger the compensating transaction.

In this approach, there is no central coordinator, and the services communicate with each other directly to coordinate the execution of the transactions and compensations. The state of the Saga is maintained by the services themselves, which keep track of the status of their own transactions and respond to messages or events from other services.

This approach provides a more scalable and flexible solution, as each service can be developed and deployed independently and can handle its own transactions and compensations. However, it also requires a higher level of coordination and cooperation between the services, and it can be more complex to design and implement the compensations.

Overall, the choreography-based approach to implementing the Saga design pattern is suitable for scenarios where decentralization and autonomy are desired, and where the complexity of the compensations can be handled by the services themselves. However, it may not be the best choice for scenarios where central control and coordination are required.

The orchestration-based approach to implementing the Saga design pattern is a central coordinator-based mechanism, where a central coordinator is responsible for managing the execution of the transactions and compensations. The central coordinator communicates with the local transactions, sending commands to execute transactions and triggering compensations if necessary.

In this approach, the central coordinator is responsible for maintaining the state of the Saga, keeping track of the status of each transaction, and making decisions on what actions to take based on the status of the transactions. If a transaction fails, the coordinator sends a compensation command to undo the changes made by the failed transaction.

This approach provides a centralized control over the Saga and ensures that the transactions are executed in the correct order. However, it also has some drawbacks, such as increased complexity, a single point of failure, and the need for strong consistency guarantees, which can be difficult to achieve in a distributed system.

Overall, the orchestration-based approach to implementing the Saga design pattern is suitable for scenarios where central control is required and a high degree of coordination and consistency is desired. However, it may not be the best choice for large and complex systems, where scalability and reliability are key requirements.

The main difference between choreography and orchestration in the context of the Saga design pattern is the level of centralization and control over the execution of the transactions and compensations.

Difference between orchestration vs Choreography:

Orchestration refers to a centralized mechanism, where a central coordinator is responsible for managing the execution of the transactions and compensations. The central coordinator communicates with the local transactions, sending commands to execute transactions and triggering compensations if necessary.

Choreography, on the other hand, refers to a decentralized mechanism, where each local transaction is executed as an independent service and communicates with other services through messages or events. If a transaction fails, it sends a compensation message or event to trigger the compensating transaction.

Orchestration provides a high degree of central control and coordination over the Saga, and ensures that the transactions are executed in the correct order. However, it also has some drawbacks, such as increased complexity, a single point of failure, and the need for strong consistency guarantees, which can be difficult to achieve in a distributed system.

Choreography, on the other hand, provides a more scalable and flexible solution, as each service can be developed and deployed independently and can handle its own transactions and compensations. However, it also requires a higher level of coordination and cooperation between the services, and it can be more complex to design and implement the compensations.

The choice between choreography and orchestration depends on the specific requirements and constraints of the system, such as the need for central control, the number of services involved, the level of independence and autonomy of the services, and the need for scalability and reliability.

Java 17 Features

 Some of the new features and improvements introduced in Java 17 include:

1. Sealed Classes: Sealed classes provide a way to limit the implementation of a class to a specific set of classes or interfaces, making it easier to enforce contracts and reduce the risk of errors.

2. Records: Records provide a compact and easy-to-use syntax for declaring simple data classes that represent an immutable value.

3. Pattern Matching for instanceof: Java 17 introduces pattern matching for the instanceof operator, making it easier to write type-safe and concise code.

4. Improved Concurrency: Java 17 includes several improvements to the Java concurrency API, including the addition of new classes and methods to simplify the development of concurrent applications.

5. Text Blocks: Java 17 includes text blocks, a new feature that makes it easier to work with multi-line string literals in your code.

6. Foreign Linker API: Java 17 introduces the Foreign Linker API, which provides a way to link native code and libraries directly into a Java program, improving the performance and integration of Java applications with native code.

Here is the example of sealed class

sealed interface Shape permits Circle, Rectangle { }

final class Circle implements Shape {

    private final double radius;

    public Circle(double radius) {

        this.radius = radius;

    }

    public double getRadius() {

        return radius;

    }

}

final class Rectangle implements Shape {

    private final double length;

    private final double width;

    public Rectangle(double length, double width) {

        this.length = length;

        this.width = width;

    }

    public double getLength() {

        return length;

    }

    public double getWidth() {

        return width;

    }

}

In this example, Shape is a sealed interface that permits the classes Circle and Rectangle to implement it. This means that no other classes can implement the Shape interface. By using sealed classes, you can restrict the types that can implement an interface and ensure type safety in your code.

Java Records is a new feature introduced in Java 16 that provides a compact syntax for declaring classes that are purely transparent data carriers. Records are a way to define simple data classes that have a private final field for each component, a public constructor, and automatically generated accessor methods (getters), equals, hashCode and toString methods.

Here is an example of how you could define a Person record in Java:

record Person(String name, int age) { }

This record definition is equivalent to the following class definition:

class Person { private final String name; private final int age; public Person(String name, int age) { this.name = name; this.age = age; } public String getName() { return name; } public int getAge() { return age; } @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; Person person = (Person) o; return age == person.age && Objects.equals(name, person.name); } @Override public int hashCode() { return Objects.hash(name, age); } @Override public String toString() { return "Person{" + "name='" + name + '\'' + ", age=" + age + '}'; } }

With records, you can define data classes in a more concise and readable way, while still having the benefits of automatically generated accessor methods, equals, hashCode, and toString methods.

Pattern matching in Java is a new feature introduced in Java 16/17 that provides a more concise and type-safe way to perform type checking and extract values from objects. With pattern matching, you can use the instanceof operator in a switch expression to match objects against a specific pattern and extract values from the matched object.

Here's an example of how you could use pattern matching in a switch expression to match an object against a specific type and extract values from the matched object:

public static void printArea(Shape shape) {

    switch (shape) {

        case Circle c:

            System.out.println("The area of the circle is " + Math.PI * c.getRadius() * c.getRadius());

            break;

        case Rectangle r:

            System.out.println("The area of the rectangle is " + r.getLength() * r.getWidth());

            break;

        default:

            System.out.println("Unknown shape");

            break;

    }

}

In this example, the printArea method takes a Shape object as an argument and uses a switch expression to match the object against specific patterns. If the object is a Circle object, the radius is extracted and used to calculate the area. If the object is a Rectangle object, the length and width are extracted and used to calculate the area. If the object is not a Circle or a Rectangle, the default case is executed and an "Unknown shape" message is printed.

Pattern matching provides a more concise and type-safe way to perform type checking and extract values from objects, and can make your code more readable and maintainable.

In Java, pattern matching is performed using the instanceof operator in a switch expression. The instanceof operator is used to check the type of an object and determine whether it matches a specified pattern.

Here's an example of how you could use the instanceof operator in a switch expression to match an object against a specific type and extract values from the matched object:

public static void printArea(Object shape) { if (shape instanceof Circle) { Circle c = (Circle) shape; System.out.println("The area of the circle is " + Math.PI * c.getRadius() * c.getRadius()); } else if (shape instanceof Rectangle) { Rectangle r = (Rectangle) shape; System.out.println("The area of the rectangle is " + r.getLength() * r.getWidth()); } else { System.out.println("Unknown shape"); } }

In this example, the printArea method takes an Object object as an argument and uses the instanceof operator in an if-else statement to check the type of the object. If the object is a Circle object, the radius is extracted and used to calculate the area. If the object is a Rectangle object, the length and width are extracted and used to calculate the area. If the object is not a Circle or a Rectangle, the else case is executed and an "Unknown shape" message is printed.

The instanceof operator can be useful for performing type checking and extracting values from objects, but it can also lead to code that is verbose and harder to maintain. The introduction of pattern matching in Java 16 provides a more concise and type-safe way to perform type checking and extract values from objects.

AWS Security- GuardDuty

 GuardDuty is an intelligent threat detection service

identifies malicious activity or unauthorised activities, such as anomalous behaviour, credential exfiltration, or command and control infrastructure (C2) communication is detected.

GuardDuty provides broad security monitoring of your AWS accounts, workloads, and data to help identify threats, such as attacker reconnaissance; instance, account, bucket, or Amazon EKS cluster compromises; and malware

GuardDuty is a regional service

GuardDuty analyses CloudTrail data events for Amazon S3 logs, CloudTrail management event logs, DNS logs, Amazon EBS volume data, Kubernetes audit logs, Amazon VPC flow logs, and RDS login activity.

Able to send notifications using cloudwatch events.

produces security reports called findings.

GuardDuty does not look at historical data,

GuardDuty operates completely independent of your AWS resources and therefore should have no impact on the performance or availability of your accounts or workloads.

GuardDuty does not manage or retain your logs

Not capable of doing any resource changes, like rate-limiting protection or DDOS attack migration.

https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html.

Unauthorised infra, unusual api calls, password strengths etc,,,

AWS Security- AWS Shield

 AWS Shield: Managed DDOS Protection service

- provides protection against Distributed Denial of Service (DDoS) attacks for applications running on AWS.

Shield comes with 2 tiers: Standard and Advanced

-AWS Shield Standard is automatically enabled to all AWS customers at no additional cost

- AWS Shield Advanced is an optional paid service,  provides additional protections against more sophisticated and larger attacks for your applications running on Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Route 53. DRT support during DDOS attacks

-Mitigate different type of flood attacks (layer 3 and 4) attacks such as SYN/UDP floods, reflection attacks

Protects the applications that use Amazon EC2, Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Route 53

Pricing

• Shield Standard  no additional charge.
• Shield Advanced paid service, requires a 1-year subscription commitment and charges a monthly fee, plus a usage fee based on data transfer out from CloudFront, ELB, EC2, and AWS Global Accelerator.

https://aws.amazon.com/shield/faqs/

AWS Security- WAF

 WAF-- Web Application Firewall service

WAF protect web applications from common web exploits.

WAF allows you to create custom rules that block common web exploits like SQL injection and cross site scripting.

WAF lets you create rules to filter web traffic based on conditions that include IP addresses, HTTP headers and body, or custom URIs.

WAF can be integrated with Cloudfront, ALB, API Gateway and AWS AppSync

WAF charges based on the number of web ACL, no.of rules that you add per web ACL, and the number of web requests that you receive.

WAF provides Geo match condition, blocks requests from certain countries, allow request only from certain countries.

https://aws.amazon.com/waf/faqs/

https://aws.amazon.com/waf/features/

https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html