CAP theorem means if there is network partition and if you want your system to keep functioning you can provide either Availability or Consistency and not both.

Understanding the CAP theorem: https://dzone.com/articles/understanding-the-cap-theorem

Write-ahead logging

In a system using WAL (write-ahead logging), all modifications are written to a log before they are applied. Usually both redo and undo information is stored in the log.

Example. Imagine a program that is in the middle of performing some operation when the machine it is running on loses power. Upon restart, that program might need to know whether the operation it was performing succeeded, succeeded partially, or failed. If a write-ahead log is used, the program can check this log and compare what it was supposed to be doing when it unexpectedly lost power to what was actually done. On the basis of this comparison, the program could decide to undo what it had started, complete what it had started, or keep things as they are.

WAL in Spark Streaming: https://bit.ly/2Otr22i
WAL in MySQL: https://bit.ly/2B8EN3E

Open/Closed Principle and Strategy Pattern

The Open Closed Principle: Software entities should be open to extension but closed to modification.

Strategy Pattern: behavioural software design pattern that enables selecting an algorithm at runtime.

About Open/Closed Principle and how to achieve it with Strategy Pattern: https://dzone.com/articles/the-openclosed-principle

Java Records

Records - classes that act as transparent carriers for immutable data. Records can be thought of as nominal tuples. Similar structures in Kotlin: data classes, in Scala: case classes.

Records were proposed in mid 2019 and delivered in JDK 14 in early 2020 as a preview feature. This JEP 384 proposes to re-preview the feature in JDK 15 (will be released in August).

A closer look at Records: https://dzone.com/articles/java-records-a-closer-look

Very often people think that function (method) should be extracted only to move duplicated code into one place. But it's only one reason.

#CleanCode Function Rules

- Small (function should be as small as possible)
- Do one thing (single responsibility principle for function)
- Use descriptive names (function name should describe what function does)
- Prefer fewer arguments
- Have no side effects (function should not change variables outside its scope)
- Don't use flag arguments (split method into several independent methods that can be called from the client without the flag)

Details and example: https://dzone.com/articles/clean-code-functions

The actor model in computer science is a mathematical model of concurrent computation that treats actor as the universal primitive of concurrent computation.

An actor is a computational entity that, in response to a message it receives, can concurrently:
- send a finite number of messages to other actors;
- create a finite number of new actors;
- designate the behavior to be used for the next message it receives.

Based on message passing technique.

The most popular implementations:
Java/Scala - Akka
.NET - Akka.NET

Actor model in wiki: https://en.wikipedia.org/wiki/Actor_model
The actor model in 10 minutes: https://www.brianstorti.com/the-actor-model/

KISS principle

KISS, an acronym for "keep it simple, stupid" or "keep it stupid simple", is a design principle. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.

A Detailed Explanation of The KISS Principle in Software: https://thevaluable.dev/kiss-principle-explained/

Circuit Breaker Pattern

Circuit Breaker pattern is used to detect failures and encapsulates the logic of preventing a failure from constantly recurring, during maintenance, temporary external system failure or unexpected system difficulties.

In simple words: allows us to save resources when we know a remote service failed. Useful when all parts of our application are highly decoupled from each other, and failure of one component doesn't mean the other parts will stop working.

Details and Spring example: https://dzone.com/articles/circuit-breaker-pattern

Martin Fowler's explanation: https://martinfowler.com/bliki/CircuitBreaker.html

The Open-Closed Principle at an Architectural Level

At a class level, the Open-Closed Principle (OCP) states that a class is opened for extension but closed to modification, meaning that you should be able to extend a class's behavior without modifying it. This is usually done by extending the class, either using inheritance or composition.

At an architectural level, we are not trying to modify the functionality of a piece of the system (a process, daemon, service, or microservice that best suits your architecture) but, instead, add new pieces leveraging the work you've already done.

Read more: https://dzone.com/articles/the-open-closed-principle-at-an-architectural-leve

A flag argument is a kind of function argument that tells the function to carry out a different operation depending on its value.

Why it is bad and how to avoid it: https://8thlight.com/blog/dariusz-pasciak/2015/05/28/alternatives-to-boolean-parameters.html

​​​​Think you understand the Single Responsibility Principle?

According to Wikipedia SRP means that a class should only have one responsibility, which is further defined by Robert Martin as ‘one reason to change’.

However in this article Robert Martin goes into what he is thinking in rather more depth than usual. In this he gives ‘another wording for the SRP’:

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

Read more: https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137

Robert Martin's explanation: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

​​API Gateway Pattern

In non-technical terms, "a gateway or a gate is a point of entry to space which is enclosed by walls." Similarly, a gateway in software terminology acts as an entry point to your servers sitting inside a firewall or intranet. In the microservices world, a gateway sits in front of your APIs that are facing clients and acts as a reverse proxy. 

API gateways have become one of the key components in the microservices architecture pattern.

Read more: https://dzone.com/articles/gateway-pattern
Spring Cloud implementation: https://www.baeldung.com/spring-cloud-gateway

Side Effect Methods. Good, Bad and Ugly

Good : Not changing the state of the parameters passed, returning a value from the method.

Bad : Changing the state of the parameters passed, however method does not return a value.

The Ugly: Changing the state of the parameters passed and also returning a value from the method.

https://telegra.ph/Side-Effect-Methods-Good-Bad-and-Ugly-08-13

Chain of Responsibility as a design pattern consisting of a source of command objects and a series of processing objects.

Each processing object in the chain is responsible for a certain type of command, and the processing is done, it forwards the command to the next processor in the chain.

The Chain of Responsibility pattern is handy for:

- Decoupling a sender and receiver of a command (loose coupling)
- Picking a processing strategy at processing-time

Details and Java example: https://bit.ly/31ZxGUr
.NET example: https://bit.ly/31Y3RDN
Scala example: https://bit.ly/2DRDXd3

Martin Fowler describes the Extract Method refactoring pattern like this:

You have a code fragment that can be grouped together.
Turn the fragment into a method whose name explains the purpose of the method.

Details and example: https://refactoring.guru/extract-method

Layered Pattern

The layered pattern is probably one of the most well-known software architecture patterns. Many developers use it, without really knowing its name. The idea is to split up your code into “layers”, where each layer has a certain responsibility and provides a service to a higher layer.

Read more: https://towardsdatascience.com/software-architecture-patterns-98043af8028

Eventual consistency is a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. A system that has achieved eventual consistency is often said to have converged, or achieved replica convergence. Eventual consistency is a weak guarantee – most stronger models, like linearizability are trivially eventually consistent, but a system that is merely eventually consistent does not usually fulfill these stronger constraints.

Eventually-consistent services are often classified as providing BASE (Basically Available, Soft state, Eventual consistency) semantics, in contrast to traditional ACID (Atomicity, Consistency, Isolation, Durability) guarantees.

Wikipedia: https://en.wikipedia.org/wiki/Eventual_consistency
Eventual Consistency in Cassandra: https://blog.imaginea.com/consistency-tuning-in-cassandra/