{"@attributes":{"version":"2.0"},"channel":{"title":"DEV Community: Nested Software","description":"The latest articles on DEV Community by Nested Software (@nestedsoftware).","link":"https:\/\/dev.to\/nestedsoftware","image":{"url":"https:\/\/media2.dev.to\/dynamic\/image\/width=90,height=90,fit=cover,gravity=auto,format=auto\/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F59384%2Faeea81a5-33f5-4ed8-89d9-6ec48ad4bd8e.png","title":"DEV Community: Nested Software","link":"https:\/\/dev.to\/nestedsoftware"},"language":"en","item":[{"title":"Generics and Variance with Java","pubDate":"Sat, 20 Sep 2025 23:11:45 +0000","link":"https:\/\/dev.to\/nestedsoftware\/generics-and-variance-with-java-27a2","guid":"https:\/\/dev.to\/nestedsoftware\/generics-and-variance-with-java-27a2","description":"

In this article, we\u2019ll learn about generics in Java, with an emphasis on the concept of variance.<\/p>\n\n

\n \n \n Substitution of values\n<\/h1>\n\n

Let's start by introducing types and subtypes. Java supports assigning a subclass value to a variable of a base type. This is known as a widening reference assignment. We can therefore say that a Float is a subtype of a Number:
\n<\/p>\n\n

\n
Float<\/span> myFloat<\/span> =<\/span> Float<\/span>.<\/span>valueOf<\/span>(<\/span>3.14f<\/span>);<\/span>\nNumber<\/span> number<\/span> =<\/span> myFloat<\/span>;<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
\n  \n  \n  Arrays are covariant and reified\n<\/h1>\n\n
Variance tells us what happens to this subtyping relationship when the original types are placed in the context of another type. <\/p>\n\n
Let's take arrays, for example. We can ask, since Float is a subtype of Number, what can we say about an array of Floats relative to an array of Numbers?<\/p>\n\n
It turns out that in Java, arrays are covariant. That is, we can also assign an array of floats to an array of numbers:
\n<\/p>\n\n
\n
Float<\/span>[]<\/span> floats<\/span> =<\/span> new<\/span> Float<\/span>[<\/span>10<\/span>];<\/span>\nNumber<\/span>[]<\/span> numbers<\/span> =<\/span> floats<\/span>;<\/span> \/\/compiles due to covariance <\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
When we use the term covariant here, we mean that if a type like Float is a subtype of Number, then an array of Floats is also a subtype of an array of Numbers.<\/p>\n\n
The subtyping relationship for arrays goes in the same direction as the underlying types and is therefore covariant.<\/p>\n\n
Notice that in the case of Float and Number, subtyping is implemented using inheritance, but an array of Floats is also a subtype of an array of Numbers. We can say that subtyping is a more general concept than inheritance. <\/p>\n\n
The way that covariance is implemented for arrays does introduce a potential flaw into Java applications. A developer can write code to insert an object of the wrong type into the floats<\/code> array below, yet that code will successfully compile:
\n<\/p>\n\n
\n
Float<\/span>[]<\/span> floats<\/span> =<\/span> new<\/span> Float<\/span>[<\/span>10<\/span>];<\/span> \nNumber<\/span>[]<\/span> numbers<\/span> =<\/span> floats<\/span>;<\/span> \nInteger<\/span> integer<\/span> =<\/span> 3<\/span>;<\/span> \/\/auto-boxing<\/span>\nnumbers<\/span>[<\/span>0<\/span>]<\/span> =<\/span> integer<\/span>;<\/span> \/\/compiles but not safe<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Type information for arrays is compiled into the bytecode and is available at runtime. In fact, we can use instanceof<\/code> as follows for arrays:
\n<\/p>\n\n
\n
Integer<\/span>[]<\/span> integers<\/span> =<\/span> new<\/span> Integer<\/span>[<\/span>10<\/span>];<\/span>\nObject<\/span> o<\/span> =<\/span> integers<\/span>;<\/span>\nif<\/span> (<\/span>o<\/span> instanceof<\/span> Float<\/span>[])<\/span> {<\/span> \/\/ false at runtime<\/span>\n    \/\/ etc...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Another way to put it is that arrays in Java are reified. Since arrays are reified, the Java runtime knows that we are trying to put an Integer into an array of Floats. When we try to actually run the line of code numbers[0] = integer<\/code>, the application will throw an ArrayStoreException<\/code>. <\/p>\n\n
The way covariance has been implemented for arrays in Java has a defect, but at least a buggy piece of code that tries to put the wrong type into an array will fail fast at runtime.<\/p>\n\n
\n  \n  \n  Generics\n<\/h1>\n\n
\n  \n  \n  Collections before Java 5\n<\/h2>\n\n
Originally, Java did not have support for generics. These were added in Java 5. Prior to the introduction of generics, developers would have to cast to the desired type, and they would have to manually ensure that this cast was safe at runtime.
\n<\/p>\n\n
\n
List<\/span> strings<\/span> =<\/span> new<\/span> ArrayList<\/span>();<\/span>\nstrings<\/span>.<\/span>add<\/span>(<\/span>3<\/span>);<\/span> \/\/ compiles<\/span>\nString<\/span> string<\/span> =<\/span> (<\/span>String<\/span>)<\/span> strings<\/span>.<\/span>get<\/span>(<\/span>0<\/span>);<\/span> \/\/ ClassCastException at runtime<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
In Java 5, generics were introduced, and support for generics was added to the collections library as well. With generics, we can make collections typesafe:
\n<\/p>\n\n
\n
List<\/span><<\/span>String<\/span>><\/span> strings<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\nstrings<\/span>.<\/span>add<\/span>(<\/span>3<\/span>);<\/span> \/\/ does not compile<\/span>\nstrings<\/span>.<\/span>add<\/span>(<\/span>\"hello world\"<\/span>);<\/span> \/\/compiles<\/span>\nString<\/span> string<\/span> =<\/span> strings<\/span>.<\/span>get<\/span>(<\/span>0<\/span>);<\/span> \/\/type safe, no explicit cast needed<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
\n  \n  \n  Basics of generics\n<\/h2>\n\n
A class can be parameterized to one or more generic type parameters. For example, the following Pair<\/code> class supports creating a tuple of two arbitrary items:
\n<\/p>\n\n
\n
public<\/span> class<\/span> Pair<\/span><<\/span>K<\/span>,<\/span> V<\/span>><\/span> {<\/span>\n    private<\/span> final<\/span> K<\/span> first<\/span>;<\/span>\n    private<\/span> final<\/span> V<\/span> second<\/span>;<\/span>\n\n    public<\/span> Pair<\/span>(<\/span>K<\/span> first<\/span>,<\/span> V<\/span> second<\/span>)<\/span> {<\/span>\n        this<\/span>.<\/span>first<\/span> =<\/span> first<\/span>;<\/span>\n        this<\/span>.<\/span>second<\/span> =<\/span> second<\/span>;<\/span>\n    }<\/span>\n}<\/span>\n\nPair<\/span><<\/span>String<\/span>,<\/span> Integer<\/span>><\/span> p<\/span> =<\/span> new<\/span> Pair<\/span><>(<\/span>\"age\"<\/span>,<\/span> 30<\/span>);<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
We can also place a base class or interface as a constraint on the upper bound for the type parameter. Additional interfaces can also be added to the bound. For example, the following Repository<\/code> class is parameterized to a type that must be an entity, and that entity must also be serializable and comparable to other entities of the same type:
\n<\/p>\n\n
\n
class<\/span> Repository<\/span> <<\/span>T<\/span> extends<\/span> Entity<\/span> &<\/span> Serializable<\/span> &<\/span> Comparable<\/span><<\/span>T<\/span>>><\/span> {<\/span>\n    \/\/ etc...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
\n  \n  \n  Recursive type bounds\n<\/h2>\n\n
As we can see in the previous example, type parameters are occasionally defined recursively, i.e. our type T<\/code> was supplied as a parameter to Comparable<\/code>. <\/p>\n\n
In the following example, we create our own interface, similar to Java\u2019s Comparable<\/code>. Rather than allowing the compareTo<\/code> method to apply to any arbitrary type, here we arrange for MyComparable<\/code> to apply to the specific class or interface that implements our MyComparable<\/code> interface:
\n<\/p>\n\n
\n
public<\/span> interface<\/span> MyComparable<\/span><<\/span>T<\/span> extends<\/span> MyComparable<\/span><<\/span>T<\/span>>><\/span> {<\/span>\n    int<\/span> compareTo<\/span>(<\/span>T<\/span> other<\/span>);<\/span>\n}<\/span>\n\npublic<\/span> class<\/span> MyInteger<\/span> implements<\/span> MyComparable<\/span><<\/span>MyInteger<\/span>><\/span> {<\/span>\n    public<\/span> int<\/span> compareTo<\/span>(<\/span>MyInteger<\/span> otherInteger<\/span>)<\/span> {<\/span>\n        \/\/ ...<\/span>\n    }<\/span>\n}<\/span>\n\npublic<\/span> class<\/span> MyFloat<\/span> implements<\/span> MyComparable<\/span><<\/span>MyFloat<\/span>><\/span> {<\/span>\n    public<\/span> int<\/span> compareTo<\/span>(<\/span>MyFloat<\/span> otherFloat<\/span>)<\/span> {<\/span>\n        \/\/ ...<\/span>\n    }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
This pattern is sometimes used for builders, to support a fluent interface for a subclassed builder, such that it can return itself to continue chaining calls. It's also used behind the scenes for Java enums:
\n<\/p>\n\n
\n
\/\/from openjdk source code<\/span>\npublic<\/span> abstract<\/span> class<\/span> Enum<\/span><<\/span>E<\/span> extends<\/span> Enum<\/span><<\/span>E<\/span>>><\/span> implements<\/span> Constable<\/span>,<\/span> Comparable<\/span><<\/span>E<\/span>>,<\/span> Serializable<\/span> {<\/span>\n    \/\/ ...<\/span>\n}<\/span>\n\npublic<\/span> enum<\/span> MyEnum<\/span> {<\/span>\n    VAL1<\/span>,<\/span>\n    VAL2<\/span>\n}<\/span>\n\n\/\/ it's not legal to write code like this, but MyEnum does extend Enum<MyEnum><\/span>\npublic<\/span> class<\/span> MyEnum<\/span> extends<\/span> Enum<\/span><<\/span>MyEnum<\/span>><\/span> {<\/span> \n    \/\/ ...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
\n  \n  \n  Generic type parameters for methods\n<\/h2>\n\n
Generic type parameters can also be applied directly to a method declaration:
\n<\/p>\n\n
\n
public<\/span> static<\/span> <<\/span>T<\/span>><\/span> T<\/span> firstElement<\/span>(<\/span>List<\/span><<\/span>T<\/span>><\/span> items<\/span>)<\/span> {<\/span>\n    return<\/span> items<\/span>.<\/span>get<\/span>(<\/span>0<\/span>);<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
As with classes, we can define upper bounds for the type parameters for methods:
\n<\/p>\n\n
\n
public<\/span> static<\/span> <<\/span>T<\/span> extends<\/span> MyService<\/span> &<\/span> Closeable<\/span>><\/span> MyResourceWrapper<\/span><<\/span>T<\/span>><\/span> of<\/span>(<\/span>T<\/span> input<\/span>)<\/span> {<\/span>\n    \/\/ etc...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
\n  \n  \n  Generic type parameters are invariant and not reified\n<\/h2>\n\n
Unlike arrays, generics are not covariant - they are invariant. For example, the following will not compile:
\n<\/p>\n\n
\n
List<\/span><<\/span>Number<\/span>><\/span> numbers<\/span> =<\/span> new<\/span> ArrayList<\/span><<\/span>Integer<\/span>>();<\/span> \/\/ does not compile<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
This means that while an Integer is a subtype of Number, a list of Integers is not a subtype of a list of Numbers. If this were allowed in the same way as it is with arrays, we could introduce the wrong type of object, such as a Float, into the list, and the code would still compile.<\/p>\n\n
However, with generics the problem would be worse. Unlike arrays, the type information supplied via generics is not available at runtime. This is called type erasure. In general, we cannot do the following:
\n<\/p>\n\n
\n
if<\/span> (<\/span>someObject<\/span> instanceof<\/span> List<\/span><<\/span>String<\/span>><\/span> strings<\/span>)<\/span> {<\/span>\n    \/\/ etc...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
The best we could do is something like this:
\n<\/p>\n\n
\n
if<\/span> (<\/span>o<\/span> instanceof<\/span> List<\/span><?><\/span> someList<\/span>)<\/span> {<\/span>\n    \/\/ etc...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
When generics were introduced in Java 5, the designers decided not to include the type information for objects with generic type parameters in the bytecode, in order to  maintain backward compatibility with older versions of Java. <\/p>\n\n
Therefore, unlike arrays, generics are not reified. Behind the scenes, the compiled bytecode still casts to the desired type. It's just that this casting is deemed safe given that the code has been compiled successfully. This remains the case in modern Java.<\/p>\n\n
Because generics are not reified, the runtime doesn't associate an instance of a collection with any particular type. If collections were covariant, that means we could successfully insert the wrong type of object into a collection at runtime, and we would only get a runtime error at some point in the future, when we tried to use that object later on. <\/p>\n\n
When the wrong type of object is successfully introduced at runtime like this, it's called heap pollution. Heap pollution can still occur in Java in a number of ways, e.g. when mixing generics with arrays and varargs. It can happen if the developer makes unsafe casts or uses raw collections, or via reflection as well. However, for the most part, generics help us to make our Java code typesafe.<\/p>\n\n
\n  \n  \n  Variance and PECS\n<\/h2>\n\n
While generic type parameters are invariant, there is support for variance with generics in the form of wildcard type parameters. A well known acronym, PECS, which stands for \"producer extends, consumer super\" is often used as a mnemonic when thinking about variance. We will go into more detail to explain variance and this acronym below.<\/p>\n\n
\n  \n  \n  Covariance\n<\/h3>\n\n
Wildcard type parameters cannot be used as part of a generic type declaration. That is to say, in Java, variance for generics is expressed at the use site.<\/p>\n\n
The following is an example of a wildcard type parameter being used for a variable declaration:
\n<\/p>\n\n
\n
List<\/span><?<\/span> extends<\/span> Number<\/span>><\/span> numbers<\/span> =<\/span> new<\/span> ArrayList<\/span><<\/span>Float<\/span>>();<\/span>\nnumbers<\/span> =<\/span> new<\/span> ArrayList<\/span><<\/span>Integer<\/span>>();<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
In the above code, we can say that a list of Integers or Floats is a subtype of a list of covariant Numbers. <\/p>\n\n
Why is this useful? Let's say we've written a class MyStack<\/code> which offers standard stack operations like push<\/code> and pop<\/code>. Now we wish to add a pushAll<\/code> method which allows us to push multiple items at a time onto our stack. We could try something like this:
\n<\/p>\n\n
\n
public<\/span> class<\/span> MyStack<\/span><<\/span>T<\/span>><\/span> {<\/span>\n    \/\/ other methods like push, pop, etc. not shown<\/span>\n\n    public<\/span> void<\/span> pushAll<\/span>(<\/span>List<\/span><<\/span>T<\/span>><\/span> items<\/span>)<\/span> {<\/span>\n        for<\/span> (<\/span>T<\/span> item<\/span> :<\/span> items<\/span>)<\/span> {<\/span>\n            push<\/span>(<\/span>item<\/span>);<\/span>\n        }<\/span>\n    }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
However, this means that if we have a stack of Numbers, we cannot push the items from a stack of Integers onto our stack, since generics are invariant:
\n<\/p>\n\n
\n
List<\/span><<\/span>Integer<\/span>><\/span> integers<\/span> =<\/span> List<\/span>.<\/span>of<\/span>(<\/span>1<\/span>,<\/span> 2<\/span>,<\/span> 3<\/span>);<\/span>\nMyStack<\/span><<\/span>Number<\/span>><\/span> numbers<\/span> =<\/span> new<\/span> MyStack<\/span><>();<\/span>\nnumbers<\/span>.<\/span>pushAll<\/span>(<\/span>integers<\/span>);<\/span> \/\/ does not compile<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
In principle, there is no harm in having integers on our stack, but the compiler cannot allow a List<Integer><\/code> where a List<Number<\/code>> is expected, because this could cause heap pollution, as mentioned earlier.<\/p>\n\n
We can solve this problem with covariance:
\n<\/p>\n\n
\n
public<\/span> class<\/span> MyStack<\/span><<\/span>T<\/span>><\/span> {<\/span>\n    \/\/ other methods like push, pop, etc. not shown<\/span>\n\n    public<\/span> void<\/span> pushAll<\/span>(<\/span>List<\/span><?<\/span> extends<\/span> T<\/span>><\/span> items<\/span>)<\/span> {<\/span>\n        for<\/span> (<\/span>T<\/span> item<\/span> :<\/span> items<\/span>)<\/span> {<\/span>\n            push<\/span>(<\/span>item<\/span>);<\/span>\n        }<\/span>\n    }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Covariance with wildcards also lets us write code along the following lines:
\n<\/p>\n\n
\n
public<\/span> static<\/span> <<\/span>T<\/span>><\/span> List<\/span><<\/span>T<\/span>><\/span> combine<\/span>(<\/span>List<\/span><?<\/span> extends<\/span> List<\/span> <?<\/span> extends<\/span> T<\/span>>><\/span> listOfLists<\/span>)<\/span> {<\/span>\n    \/\/ etc...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
In the above code, we are able to combine the supplied lists together, regardless of how many different subclasses of type <T><\/code> there may be.<\/p>\n\n
To prevent the issues that covariant arrays have, the compiler imposes a restriction on how wildcards can be used. In the case of the pushAll<\/code> method, the compiler knows every individual item in items<\/code> must be a number, so pushing onto our stack is typesafe. <\/p>\n\n
However, we don't know what is actually passed in - it could be a List<Number><\/code>, a List<Integer><\/code>, a List<Float<\/code>, etc. Because of this, the following code doesn't compile:
\n<\/p>\n\n
\n
public<\/span> static<\/span> double<\/span> averageOrDefault<\/span>(<\/span>List<\/span><?<\/span> extends<\/span> Number<\/span>><\/span>numbers<\/span>)<\/span> {<\/span>\n    if<\/span> (<\/span>numbers<\/span>.<\/span>isEmpty<\/span>())<\/span> {<\/span>\n        numbers<\/span>.<\/span>add<\/span>(<\/span>0<\/span>);<\/span> \/\/ does not compile<\/span>\n    }<\/span>\n    return<\/span> average<\/span>(<\/span>numbers<\/span>);<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
The reason is that we could call this method with List<Integer><\/code> but also with some other lists of Numbers:
\n<\/p>\n\n
\n
List<\/span><<\/span>Integer<\/span>><\/span> integers<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\naverageOrDefault<\/span>(<\/span>integers<\/span>);<\/span> \/\/ compiles<\/span>\n\nList<\/span><<\/span>Float<\/span>><\/span> floats<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\naverageOrDefault<\/span>(<\/span>floats<\/span>);<\/span> \/\/ compiles<\/span>\n\nList<\/span><<\/span>Number<\/span>><\/span> numbers<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\naverageOrDefault<\/span>(<\/span>numbers<\/span>);<\/span> \/\/ also compiles<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
With a covariant generic type, null<\/code> is the only valid argument that can be passed in to such a method, since null<\/code> isn't specific to any particular type.<\/p>\n\n
That's the reason for the \"producer extends\" part of PECS. When we use covariance, we know any items we obtain will have the desired upper bound, but the compiler can't know for sure what the exact type is. We know that the producer can supply us with an instance that is a subtype of the upper bound on the type parameter, but we don't know which one, so the most specific we can get is to assign values to variables typed to the upper bound. Covariance is therefore used when we want to, in some sense, get items out. Hence we think of covariant generics as producers.<\/p>\n\n
\n  \n  \n  Contravariance\n<\/h3>\n\n
Now we want to implement a popAll<\/code> method for MyStack<\/code>, which pops all items from our stack and adds them to the supplied list:
\n<\/p>\n\n
\n
public<\/span> class<\/span> MyStack<\/span><<\/span>T<\/span>><\/span> {<\/span>\n    \/\/ other methods like push, pop, etc. not shown<\/span>\n\n    public<\/span> void<\/span> popAll<\/span>(<\/span>List<\/span><<\/span>T<\/span>><\/span> items<\/span>)<\/span> {<\/span>\n        while<\/span> (!<\/span>isEmpty<\/span>())<\/span> {<\/span>\n            T<\/span> popped<\/span> =<\/span> pop<\/span>();<\/span>\n            items<\/span>.<\/span>add<\/span>(<\/span>popped<\/span>);<\/span>\n        }<\/span>\n    }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
The following won't compile:
\n<\/p>\n\n
\n
List<\/span><<\/span>Object<\/span>><\/span> anything<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\nMyStack<\/span><<\/span>Integer<\/span>><\/span> integers<\/span> =<\/span> new<\/span> MyStack<\/span><>();<\/span>\nintegers<\/span>.<\/span>push<\/span>(<\/span>1<\/span>);<\/span>\nintegers<\/span>.<\/span>push<\/span>(<\/span>2<\/span>);<\/span>\nintegers<\/span>.<\/span>push<\/span>(<\/span>3<\/span>);<\/span>\nintegers<\/span>.<\/span>popAll<\/span>(<\/span>anything<\/span>);<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Even though we can see that it's safe to add integers to a list of objects, the compiler won't allow this code to compile because generics are invariant. However, we can fix this by making the argument contravariant:
\n<\/p>\n\n
\n
public<\/span> class<\/span> MyStack<\/span><<\/span>T<\/span>><\/span> {<\/span>\n    \/\/ other methods like push, pop, etc. not shown<\/span>\n\n    public<\/span> void<\/span> popAll<\/span>(<\/span>List<\/span><?<\/span> super<\/span> T<\/span>><\/span> items<\/span>)<\/span> {<\/span>\n        while<\/span> (!<\/span>isEmpty<\/span>())<\/span> {<\/span>\n            T<\/span> popped<\/span> =<\/span> pop<\/span>();<\/span>\n            items<\/span>.<\/span>add<\/span>(<\/span>popped<\/span>);<\/span>\n        }<\/span>\n    }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Now our code below will compile:
\n<\/p>\n\n
\n
List<\/span><<\/span>Object<\/span>><\/span> anything<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\n\nMyStack<\/span><<\/span>Integer<\/span>><\/span> integers<\/span> =<\/span> new<\/span> MyStack<\/span><>();<\/span>\nintegers<\/span>.<\/span>push<\/span>(<\/span>1<\/span>);<\/span>\nintegers<\/span>.<\/span>push<\/span>(<\/span>2<\/span>);<\/span>\nintegers<\/span>.<\/span>push<\/span>(<\/span>3<\/span>);<\/span>\n\nintegers<\/span>.<\/span>popAll<\/span>(<\/span>anything<\/span>);<\/span> \/\/ compiles<\/span>\n\nList<\/span><<\/span>Number<\/span>><\/span> numbers<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\nintegers<\/span>.<\/span>popAll<\/span>(<\/span>numbers<\/span>);<\/span> \/\/ also compiles<\/span>\n\nList<\/span><<\/span>Integer<\/span>><\/span> moreIntegers<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\nintegers<\/span>.<\/span>popAll<\/span>(<\/span>moreIntegers<\/span>);<\/span> \/\/ also compiles - super is inclusive<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
However, the following won't compile:
\n<\/p>\n\n
\n
List<\/span><<\/span>Float<\/span>><\/span> floats<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\nintegers<\/span>.<\/span>popAll<\/span>(<\/span>floats<\/span>);<\/span> \/\/ does not compile!<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Here we can see that contravariance allows us to safely feed items into the list, as long the type of object passed in is a subtype of the lower bound specified for the argument to the method being called. <\/p>\n\n
However, since we don't know precisely what type of list was passed in, if we want to call a method that returns an item from that list, all we can do is assign that item to Object<\/code>:
\n<\/p>\n\n
\n
List<\/span><<\/span>Object<\/span>><\/span> items<\/span>=<\/span> new<\/span> ArrayList<\/span><>();<\/span>\nitems<\/span>.<\/span>add<\/span>(<\/span>\"hello\"<\/span>);<\/span>\n\nList<\/span><?<\/span> super<\/span> Number<\/span>><\/span> contravariantNumbers<\/span> =<\/span> items<\/span>;<\/span>\nitems<\/span>.<\/span>add<\/span>(<\/span>3.14<\/span>);<\/span> \/\/ can add any subtype of number<\/span>\nfor<\/span>(<\/span>Object<\/span> o<\/span> :<\/span> contravariantNumbers<\/span>)<\/span> {<\/span> \/\/can only get Objects though<\/span>\n    System<\/span>.<\/span>out<\/span>.<\/span>println<\/span>(<\/span>\"o = \"<\/span> +<\/span> o<\/span>);<\/span> \n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Here we can say that a list of Objects is a subtype of a contravariant list of Numbers, so the variance goes in the opposite direction from Number being a subtype of Object, hence the \"contra\" in contravariance. That's why the following assignment makes sense:
\n<\/p>\n\n
\n
List<\/span><?<\/span> super<\/span> Number<\/span>><\/span> contravariantNumbers<\/span> =<\/span> new<\/span> ArrayList<\/span><<\/span>Object<\/span>>();<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
We can see that this is a mirror image of the situation with covariance. That's why contravariant types are thought of as consumers, i.e. the \"consumer super\" in PECS. With a contravariant type, we think about supplying items to it in some sense, hence it is a consumer. <\/p>\n\n
\n  \n  \n  Invariance with unbounded wildcards\n<\/h3>\n\n
We can also specify an unbounded wildcard:
\n<\/p>\n\n
\n
List<\/span><?><\/span> arbitraryList<\/span> =<\/span> new<\/span> ArrayList<\/span><<\/span>Integer<\/span>>();<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
This is useful when we don't care about the type of object. When specifying an unbounded wildcard, as with covariance we can't supply an argument other than null to methods that take parameters of the type that the class or method was parameterized to. Also, we can only assign the type parameterized values returned from methods to Object, as with contravariance. In this scenario, there a single specific type, so the code is still typesafe, but it doesn\u2019t matter what it is.<\/p>\n\n
Below are some examples where such wildcards make sense:
\n<\/p>\n\n
\n
public<\/span> boolean<\/span> containsAll<\/span>(<\/span>Collection<\/span><?><\/span> c<\/span>)<\/span> {<\/span>\n    \/\/ etc...<\/span>\n}<\/span>\n\npublic<\/span> static<\/span> int<\/span> size<\/span>(<\/span>Iterable<\/span><?><\/span> iterable<\/span>)<\/span> {<\/span>\n    \/\/ etc...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
\n  \n  \n  Combining covariance and contravariance together\n<\/h3>\n\n
The following example pulls covariance and contravariance for generics together. We copy all of the items from source<\/code> into destination<\/code>.
\n<\/p>\n\n
\n
public<\/span> static<\/span> <<\/span>T<\/span>><\/span> void<\/span> copy<\/span>(<\/span>List<\/span><?<\/span> super<\/span> T<\/span>><\/span> destination<\/span>,<\/span> List<\/span><?<\/span> extends<\/span> T<\/span>><\/span> source<\/span>)<\/span> {<\/span>\n    for<\/span> (<\/span>T<\/span> item<\/span> :<\/span> source<\/span>)<\/span> {<\/span>\n        destination<\/span>.<\/span>add<\/span>(<\/span>item<\/span>);<\/span>\n    }<\/span>\n}<\/span>\n\nList<\/span><<\/span>Integer<\/span>><\/span> integers<\/span> =<\/span> List<\/span>.<\/span>of<\/span>(<\/span>1<\/span>,<\/span> 2<\/span>,<\/span> 3<\/span>);<\/span>\nList<\/span><<\/span>Number<\/span>><\/span> numbers<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\ncopy<\/span>(<\/span>numbers<\/span>,<\/span> integers<\/span>);<\/span> \/\/ variance allows the types of the two arguments to be different<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Let's consider how the compiler treats type T<\/code> in the above example. We pass in integers<\/code> as the source, so we can infer that for this particular call, Integer<\/code> must extend T<\/code>. We pass in numbers<\/code> as the destination, so Number<\/code> must be a base type of T<\/code>. Therefore, for this scenario, T<\/code> must be Number<\/code>. <\/p>\n\n
If we passed in a List<Float><\/code> as the destination, the code would not compile, since T<\/code> would have to extend Integer<\/code>. If we passed in List<Object><\/code> as the source, that also would not compile, since T<\/code> must extend Number<\/code>. <\/p>\n\n
In this case, if the source is List<Integer><\/code>, then destination must be one of List<Object><\/code>, List<Number><\/code>, or List<Integer><\/code>:
\n<\/p>\n\n
\n
List<\/span><<\/span>Object<\/span>><\/span> objects<\/span> =<\/span> new<\/span> ArrayList<\/span><>();<\/span>\ncopy<\/span>(<\/span>objects<\/span>,<\/span> integers<\/span>);<\/span>\n\nList<\/span><<\/span>Number<\/span>><\/span> numbers<\/span> =<\/span> new<\/span> ArrayList<\/span><>(<\/span>List<\/span>.<\/span>of<\/span>(<\/span>1<\/span>,<\/span> 3.14<\/span>,<\/span> new<\/span> BigDecimal<\/span>(<\/span>\"50.500\"<\/span>));<\/span>\ncopy<\/span>(<\/span>numbers<\/span>,<\/span> integers<\/span>);<\/span>\n\nList<\/span><<\/span>Integer<\/span>><\/span> moreIntegers<\/span> =<\/span> new<\/span> ArrayList<\/span><>(<\/span>List<\/span>.<\/span>of<\/span>(<\/span>1<\/span>,<\/span> 2<\/span>,<\/span> 3<\/span>));<\/span>\ncopy<\/span>(<\/span>moreIntegers<\/span>,<\/span> integers<\/span>);<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
We could also pass in variables with wildcards:
\n<\/p>\n\n
\n
List<\/span><?<\/span> extends<\/span> Number<\/span>><\/span> covariantNumbers<\/span> =<\/span> integers<\/span>;<\/span>\nList<\/span><?<\/span> super<\/span> Number<\/span>><\/span> contravariantNumbers<\/span> =<\/span> objects<\/span>;<\/span>\ncopy<\/span>(<\/span>contravariantNumbers<\/span>,<\/span> covariantNumbers<\/span>);<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
\n  \n  \n  Declaration vs. use-site variance\n<\/h3>\n\n
As we have seen, in Java, variance for generics can only be expressed at the use site via wildcards (e.g., List<? extends T><\/code>, List<? super T><\/code>). We cannot make a generic type parameter for a class or method covariant or contravariant. <\/p>\n\n
In another JVM language, Scala, we can actually specify variance at the declaration site, i.e. the declaration of the type parameter itself. <\/p>\n\n
In the code below, Box<\/code> is covariant in T, i.e., +T<\/code>. The compiler enforces type safety for all of its methods, without wildcards. Returning T<\/code> is allowed, but accepting a T<\/code> as a parameter is not:
\n<\/p>\n\n
\n
class<\/span> Box<\/span>[<\/span>+T<\/span>](<\/span>private<\/span> var<\/span> value<\/span>:<\/span> T<\/span>)<\/span> {<\/span>\n    def<\/span> get<\/span>:<\/span> T<\/span> =<\/span> value<\/span> \/\/ compiles, T in covariant (return) position<\/span>\n    def<\/span> set<\/span>(<\/span>newValue<\/span>:<\/span> T<\/span>)<\/span>:<\/span> Unit<\/span> =<\/span> {<\/span>\n      value<\/span> =<\/span> newValue<\/span> \/\/ does not compile, covariant type T appears in contravariant position<\/span>\n    }<\/span>\n    override<\/span> def<\/span> toString<\/span>:<\/span> String<\/span> =<\/span> s<\/span>\"Box($value)\"<\/span>\n}<\/span>\n\nobject<\/span> VarianceDemo<\/span> extends<\/span> App<\/span> {<\/span>\n    val<\/span> intBox<\/span>:<\/span> Box<\/span>[<\/span>Integer<\/span>]<\/span> =<\/span> new<\/span> Box<\/span>[<\/span>Integer<\/span>](<\/span>Integer<\/span>.<\/span>valueOf<\/span>(<\/span>123<\/span>))<\/span>\n    val<\/span> numberBox<\/span>:<\/span> Box<\/span>[<\/span>Number<\/span>]<\/span> =<\/span> intBox<\/span> \/\/ compiles Integer is a subtype of Number, and Box is covariant<\/span>\n\n    println<\/span>(<\/span>intBox<\/span>.<\/span>get<\/span>)<\/span> \/\/ 123<\/span>\n    println<\/span>(<\/span>numberBox<\/span>.<\/span>get<\/span>)<\/span> \/\/ 123 as a Number<\/span>\n\n    def<\/span> printNumber<\/span>(<\/span>box<\/span>:<\/span> Box<\/span>[<\/span>Number<\/span>])<\/span>:<\/span> Unit<\/span> =<\/span>\n        println<\/span>(<\/span>s<\/span>\"Number inside: ${box.get}\"<\/span>)<\/span>\n\n    printNumber<\/span>(<\/span>intBox<\/span>)<\/span> \/\/ compiles due to covariance<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
\n  \n  \n  Type capture\n<\/h3>\n\n
Consider the following swap<\/code> method. We don't really need to specify the type parameter for this method, since we are re-organizing items that are already in the collection. Therefore it makes sense to use an unbounded wildcard:
\n<\/p>\n\n
\n
public<\/span> static<\/span> void<\/span> swap<\/span>(<\/span>List<\/span><?><\/span> list<\/span>,<\/span> int<\/span> i<\/span>,<\/span> int<\/span> j<\/span>)<\/span> {<\/span>\n    list<\/span>.<\/span>set<\/span>(<\/span>i<\/span>,<\/span> list<\/span>.<\/span>set<\/span>(<\/span>j<\/span>,<\/span> list<\/span>.<\/span>get<\/span>(<\/span>i<\/span>)));<\/span> \/\/ does not compile<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
This does pose a problem though. We can't get an item out of this list except as an Object, and that means we can't safely put that item back into the list at a different location. Whenever we use a wildcard like this, behind the scenes, Java assigns the type as an arbitrary synthetic type, such as CAP#1<\/code>. It doesn't matter what this is exactly. We can write a utility method that binds this synthetic type to a type parameter. This is called capture conversion:
\n<\/p>\n\n
\n
public<\/span> static<\/span> void<\/span> swap<\/span>(<\/span>List<\/span><?><\/span> list<\/span>,<\/span> int<\/span> i<\/span>,<\/span> int<\/span> j<\/span>)<\/span> {<\/span>\n    swapCapture<\/span>(<\/span>list<\/span>,<\/span> i<\/span>,<\/span> j<\/span>);<\/span>\n}<\/span>\nprivate<\/span> static<\/span> <<\/span>T<\/span>><\/span> void<\/span> swapCapture<\/span>(<\/span>List<\/span><<\/span>T<\/span>><\/span> list<\/span>,<\/span> int<\/span> i<\/span>,<\/span> int<\/span> j<\/span>)<\/span> {<\/span>\n    T<\/span> temp<\/span> =<\/span> list<\/span>.<\/span>get<\/span>(<\/span>i<\/span>);<\/span>\n    list<\/span>.<\/span>set<\/span>(<\/span>i<\/span>,<\/span> list<\/span>.<\/span>get<\/span>(<\/span>j<\/span>));<\/span>\n    list<\/span>.<\/span>set<\/span>(<\/span>j<\/span>,<\/span> temp<\/span>);<\/span>\n\n    \/\/ we could also implement this more concisely as follows<\/span>\n    \/\/ list.set(i, list.set(j, list.get(i)));<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
As we can see, the above code allows us to use a well-defined temp<\/code> variable so that we can swap the items in a typesafe manner.<\/p>\n\n
We could declare the swap<\/code> method with the type parameter <T><\/code> in the first place, avoiding the wildcards entirely. However, from an API design point of view, it is cleaner to use the wildcard here. If we are not referring to the same type in multiple places, it is a good practice to use wildcards.<\/p>\n\n
\n  \n  \n  Do not return variables with wildcards\n<\/h3>\n\n
While using wildcards for method parameters is appropriate, it is not generally a good practice for the return type to use a wildcard.<\/p>\n\n
This limits what the client can do, and makes it harder to chain methods that don't expect wildcards. Variance should be something that adds flexibility to an API while maintaining type safety, but it should not be an unnecessary burden on the developer using that API.<\/p>\n\n
\n  \n  \n  Additional examples\n<\/h3>\n\n
In the following example, the max<\/code> method returns the largest value from the supplied collection:
\n<\/p>\n\n
\n
public<\/span> static<\/span> <<\/span>T<\/span> extends<\/span> Object<\/span> &<\/span> Comparable<\/span><?<\/span> super<\/span> T<\/span>>><\/span> T<\/span> max<\/span>(<\/span>Collection<\/span><?<\/span> extends<\/span> T<\/span>><\/span> coll<\/span>)<\/span> {<\/span>\n \/\/ ...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
It makes sense to use a contravariant type for Comparable<? super T><\/code>, since we don't want to force <T><\/code> itself to implement the Comparable interface directly. One of its base classes or interfaces could do that instead.<\/p>\n\n
Similarly, the sort<\/code> method below also takes a Comparator<? super T><\/code>. We could pass in a list of integers as list<\/code> and a Comparator<Number><\/code> or Comparator<Object><\/code>. Both of these comparators can safely consume an Integer.
\n<\/p>\n\n
\n
public<\/span> static<\/span> <<\/span>T<\/span>><\/span> void<\/span> sort<\/span>(<\/span>List<\/span><<\/span>T<\/span>><\/span> list<\/span>,<\/span> Comparator<\/span><?<\/span> super<\/span> T<\/span>><\/span> c<\/span>)<\/span> {<\/span>\n \/\/ ...<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
In the following example from the Optional<\/code> class, the map<\/code> method takes a function that will be applied to the object already stored in the Optional. This function will be contravariant with respect to its argument and covariant with respect to its return values:
\n<\/p>\n\n
\n
public<\/span> final<\/span> class<\/span> Optional<\/span><<\/span>T<\/span>><\/span> {<\/span> \n    public<\/span> <<\/span>U<\/span>><\/span> Optional<\/span><<\/span>U<\/span>><\/span> map<\/span>(<\/span>Function<\/span><?<\/span> super<\/span> T<\/span>,<\/span> ?<\/span> extends<\/span> U<\/span>><\/span> mapper<\/span>)<\/span> {<\/span>\n        Objects<\/span>.<\/span>requireNonNull<\/span>(<\/span>mapper<\/span>);<\/span>\n        if<\/span> (!<\/span>isPresent<\/span>())<\/span> {<\/span>\n            return<\/span> empty<\/span>();<\/span>\n        }<\/span> else<\/span> {<\/span>\n            return<\/span> Optional<\/span>.<\/span>ofNullable<\/span>(<\/span>mapper<\/span>.<\/span>apply<\/span>(<\/span>value<\/span>));<\/span>\n        }<\/span>\n    }<\/span>  \n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
The following makes sense for this use-case:
\n<\/p>\n\n
\n
Function<\/span><<\/span>Number<\/span>,<\/span> String<\/span>><\/span> mapper<\/span> =<\/span> (<\/span>num<\/span>)<\/span> -><\/span> num<\/span>.<\/span>toString<\/span>();<\/span>\nOptional<\/span><<\/span>Integer<\/span>><\/span> optionalInt<\/span> =<\/span> Optional<\/span>.<\/span>of<\/span>(<\/span>3<\/span>);<\/span>\nOptional<\/span><<\/span>CharSequence<\/span>><\/span> optionalChars<\/span> =<\/span> optionalInt<\/span>.<\/span>map<\/span>(<\/span>mapper<\/span>);<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
In the above code, we can pass in any Number to our mapper<\/code> function, so passing in an Integer is fine. We can also return any subtype of String, so assigning to a base type such as CharSequence is also fine.<\/p>\n\n
\n  \n  \n  References\n<\/h1>\n\n
    \n
  • Effective Java, by Joshua Bloch (Chapter 5, Generics)<\/a><\/li>\n
  • OpenJDK source code<\/a><\/li>\n
  • Guava source code<\/a><\/li>\n
  • \nPalantir delegate processors source code<\/a>\n*Variance in Scala<\/a>\n<\/li>\n<\/ul>\n\n","category":["java","generics","oop","variance"]},{"title":"Performance and Scalability for Database-Backed Applications","pubDate":"Mon, 01 Jul 2024 05:26:27 +0000","link":"https:\/\/dev.to\/nestedsoftware\/performance-and-scalability-for-database-backed-applications-pca","guid":"https:\/\/dev.to\/nestedsoftware\/performance-and-scalability-for-database-backed-applications-pca","description":"
    The following are some techniques that I've found to be both useful and practical over the years for scaling data-intensive applications.<\/p>\n\n
    \n  \n  \n  Split Large Jobs into Smaller Parallel Jobs\n<\/h1>\n\n
    When processing large amounts of data, a very useful technique to improve performance is to break up a given job into smaller jobs that can run in parallel. Once all of the jobs have completed, the partial results can be integrated together. <\/p>\n\n
    Keep in mind that when the parallel jobs are hitting the same database, locking can become a bottleneck. Also, this approach requires that you be wary of over-taxing the database, since all of these sessions will be running concurrently.<\/p>\n\n
    For very high scalability, this type of idea can be implemented with tools like MapReduce<\/a>.<\/p>\n\n
    \n  \n  \n  Pre-fetch Data Before Processing\n<\/h1>\n\n
    I\/O latency is a common cause of performance obstacles. Replacing multiple calls to the database with a single call is often helpful. <\/p>\n\n
    Here you would pre-load data from the database and cache it in memory. That way the data can be used\/reused without requiring separate round trips to the database.<\/p>\n\n
    It's important to keep in mind the possibility that the cached data may be updated during processing, which may or may not have ramification for the given use case.<\/p>\n\n
    Storing large amounts of data in RAM also increases the resource usage of the application, so it's important to consider the tradeoffs between performance and memory usage.<\/p>\n\n
    \n  \n  \n  Batch Multiple SQL Executions into a Single Call\n<\/h1>\n\n
    Consider a batch data import job. The job may repeatedly execute SQL statements to persist data in a loop. You can instead collect a certain amount of data within the application, and issue a single SQL call to the database. This again reduces the amount of I\/O required. <\/p>\n\n
    One issue with this approach is that a single failure will cause the entire transaction to rollback. When a batch fails, you can re-run each item in that batch again one at a time so that the rest of the data can still be persisted, and only the failing records will produce an error.<\/p>\n\n
    \n
    Note: If you're sending individual SQL statements in a loop, you can also set the database commit frequency so as to commit in batches rather than for each individual row.<\/p>\n<\/blockquote>\n\n
    \n  \n  \n  Optimize SQL Queries\n<\/h1>\n\n
    Working with relational databases can be somewhat of an art form. When queries perform poorly, it can be helpful to deeply understand the execution plan used by the database engine and to improve the SQL based on that information. <\/p>\n\n
    Rewriting inefficient SQL queries as well as reviewing indexes associated with the tables in the query can help to improve performance. In Oracle, one can add database hints to help improve queries, though personally I prefer to avoid that as much as possible.<\/p>\n\n
    \n  \n  \n  Use Separate Databases\/Schemas\n<\/h1>\n\n
    Having a single large database can be convenient, but it also can introduce performance problems when there are huge numbers of rows in important tables. For example, let's say a b2b enterprise application is used by many different companies. Having a separate database or schema for each company can significantly improve performance. <\/p>\n\n
    Such partitioning also makes it easier to maintain security so that a company's data won't be accidentally accessed by the wrong users.<\/p>\n\n
    \n
    When data is broken up across multiple schemas, it may make sense to aggregate it into a single database that can be used for management and analytics - in the example above this database would have information about all of the companies in the system.<\/p>\n<\/blockquote>\n\n
    \n  \n  \n  Refactor Database Structure\n<\/h1>\n\n
    In some cases, the structure of the database tables can reduce performance significantly. <\/p>\n\n
    Sometimes breaking up a single table into multiple tables can help (this is known as normalizing the tables), as the original table structure may have a large number of nullable columns. <\/p>\n\n
    In other cases, it may be helpful to go the other way and de-normalize tables (combine data from multiple tables into a single table). This allows data to be retrieved all at once, without requiring joins. Instead of fully denormalizing the data, it may be preferable to use a materialized view.<\/p>\n\n
    Working with the indexes available on database tables can also be helpful. In general we want to avoid using indexes too much when reading large amounts of data. We also want to keep in mind that indexes increase the cost for updates to the database even as they improve reads. If we occasionally read data but frequently update that data, improving the performance of the former at the expense of the latter may be a bad idea. <\/p>\n\n
    \n  \n  \n  Organize Transactions into Sagas\n<\/h1>\n\n
    Database transactions can have a significant impact on performance, so keeping transactions small is a good idea. <\/p>\n\n
    It may be possible to break up long-running transactions into multiple transactions. What was once a single transaction becomes known as a saga. <\/p>\n\n
    For example, let\u2019s say you\u2019re building an application that handles purchases. You can save an order in an unapproved state, and then move the order through to completion in multiple steps where each step is a separate transaction. <\/p>\n\n
    With sagas, it's important to understand that the database will now have data that may later be deemed invalid - e.g. a pending order may end up not being finalized. In some cases, data that has been persisted may need to be undone at the application level rather than relying on the transaction rollback - this is known as backward recovery. Alternatively, it may be possible to fix the problems that caused the initial failure and to keep the saga going - this is called forward recovery (see Saga Patterns<\/a>).<\/p>\n\n
    \n  \n  \n  Separate Transactional Processing from Reporting and Analytics\n<\/h1>\n\n
    There is a fundamental tradeoff in database optimization when managing small transactions vs. running large reports (see OLTP vs. OLAP<\/a>). <\/p>\n\n
    When running large and complex reports, it can be helpful to maintain a reporting database that can be used just for executing reports (this can be generalized to a data warehouse). In the meantime, a transactional database can continue to be used separately by the main application logic. <\/p>\n\n
    A variation on this idea is to implement CQRS<\/a>, a pattern where we use one model for write operations and another one for read operations. Usually there are separate databases for reads and writes. <\/p>\n\n
    In both cases, the distributed nature of the databases means that changes that occur on the write side as part of a transaction won't be visible immediately on the read side - this is known as eventual consistency (see Eventual Consistency<\/a>).<\/p>\n\n
    \n  \n  \n  Split Monolith into (Micro)services\n<\/h1>\n\n
    We can take the previously mentioned idea of partitioning the database further by breaking up an application into multiple applications, each with its own database. In this case each application will communicate with the others via something like REST<\/a>, RPC (e.g. gRPC<\/a>), or a message queue (e.g. Redis<\/a>, Kafka<\/a>, or RabbitMQ<\/a>).<\/p>\n\n
    This approach offers advantages, such as more flexible development and deployment (you can develop and deploy each microservice separately). It also offers scaling benefits, since services can be orchestrated to run in different geographies, and instances of running services can be added and removed dynamically based on usage (e.g. using orchestration tools like Docker Swarm<\/a> and Kubernetes<\/a>). <\/p>\n\n
    The data for a given service can be managed more efficiently - both in terms of the amount of data and the way it is structured, since it is specific to that service.<\/p>\n\n
    Of course services also present many challenges. Modifying a service may cause bugs in other services that depend on it. It can also be difficult to understand the overall behaviour of the system when a workflow crosses many service boundaries Even something that sounds as simple as local testing can become more complex, as a given workflow may require deploying a variety of different services. <\/p>\n\n
    There can be surprising bottlenecks as well. I find this video about Netflix's migration to microservices is still very relevant: <\/p>\n\n