Software Architecture

Design rot and the SOLID principles: why working object-oriented code becomes hard to change, and the five principles that answer it.

Beginner to Intermediate9 cards · 7 qnot started

The Liskov substitution principle in SOLID: a subclass must work anywhere its parent does, keeping every promise the parent makes.

Beginner to Intermediate9 cards · 5 qnot started

The dependency inversion principle in SOLID: make business rules depend on abstractions they own, so databases and services can be swapped and faked in tests.

Beginner to Intermediate9 cards · 5 qnot started

The single responsibility principle in SOLID: give each class one reason to change, by splitting it along the people who ask for changes.

Beginner to Intermediate8 cards · 4 qnot started

The open/closed principle in SOLID: add new behaviour as new code, without editing classes that already work.

Beginner to Intermediate8 cards · 4 qnot started

The interface segregation principle in SOLID: give each client a small interface holding only the methods it calls.

Beginner to Intermediate8 cards · 4 qnot started

The Factory Method pattern: letting subclasses decide which class of object to create, so the code that uses the object never names it.

Intermediate to Advanced9 cards · 4 qnot started

The Builder pattern: constructing a complex object step by step, so a constructor with a dozen optional parameters is never needed.

Intermediate to Advanced9 cards · 4 qnot started

The Singleton pattern: guaranteeing a class has exactly one instance with a global access point, and why it is the most criticised of the 23.

Intermediate to Advanced9 cards · 4 qnot started

The Proxy pattern: a stand-in with the same interface as a real object that controls when and whether calls reach it, and the self-call it never sees.

Intermediate to Advanced9 cards · 4 qnot started

The Strategy pattern: putting each interchangeable algorithm behind one interface so the caller chooses it, and why in Python the strategy is often a function.

Intermediate to Advanced9 cards · 4 qnot started

The Observer pattern: letting many objects subscribe to one and be told when it changes, and the listener that is never unsubscribed.

Intermediate to Advanced9 cards · 4 qnot started

The Command pattern: turning a request into an object that can be queued, logged or undone, and what each command must remember to undo itself.

Intermediate to Advanced9 cards · 4 qnot started

The Template Method pattern: fixing the order of an algorithm's steps in a base class and letting subclasses supply the steps that differ.

Intermediate to Advanced9 cards · 4 qnot started

The Iterator pattern: walking a collection one element at a time without knowing how it is stored, and why a Python generator can be walked only once.

Intermediate to Advanced9 cards · 4 qnot started

The Visitor pattern: adding operations over a fixed set of classes as separate visitor classes, how double dispatch finds the right method, and why a new element class is costly.

Intermediate to Advanced9 cards · 4 qnot started

Applying the SOLID principles together: diagnosing a class that breaks several, refactoring it safely behind tests, and knowing when to stop.

Intermediate to Advanced7 cards · 5 qnot started

What design patterns are: named, reusable solutions to recurring object-oriented design problems, how the 23 classic ones are grouped, and when one costs more than it saves.

Beginner to Intermediate8 cards · 5 qnot started

The Abstract Factory pattern: creating whole families of related objects through one interface, so a program can switch every product at once.

Intermediate to Advanced8 cards · 4 qnot started

The Prototype pattern: creating new objects by copying a configured one, and the shallow copy trap that comes with it.

Intermediate to Advanced8 cards · 4 qnot started

The Adapter pattern: wrapping an existing class so it fits the interface a client already expects, without changing either side.

Intermediate to Advanced8 cards · 4 qnot started

The Decorator pattern: adding behaviour to an object by wrapping it in others with the same interface, and how it differs from Python's @ syntax.

Intermediate to Advanced8 cards · 5 qnot started

The Facade pattern: one simple interface in front of a complex subsystem, with the subsystem's classes still there for the cases the facade does not cover.

Intermediate to Advanced8 cards · 4 qnot started

The Composite pattern: treating a single object and a group of objects the same way, as in files and folders.

Intermediate to Advanced8 cards · 4 qnot started

The Bridge pattern: splitting what something is from how it is done into two hierarchies, so they grow without multiplying classes.

Intermediate to Advanced8 cards · 4 qnot started

The Flyweight pattern: sharing the common part of many small objects so that a program holding millions of them still fits in memory.

Intermediate to Advanced8 cards · 4 qnot started

The State pattern: giving each state of an object its own class, so behaviour changes when the state changes, and deciding which class chooses the next state.

Intermediate to Advanced8 cards · 4 qnot started

The Chain of Responsibility pattern: passing a request along a chain of handlers until one deals with it, and ending every chain with an answer for requests nobody accepts.

Intermediate to Advanced8 cards · 4 qnot started

The Mediator pattern: routing the communication between many objects through one coordinator, and counting the links it removes.

Intermediate to Advanced8 cards · 4 qnot started

The Memento pattern: saving an object's state as a snapshot only that object can read, so it can be restored later, and keeping the snapshots from filling the memory.

Intermediate to Advanced8 cards · 4 qnot started

The Interpreter pattern: representing each rule of a small language as a class, evaluating a sentence as a tree of those objects, and knowing that parsing is a separate job.

Intermediate to Advanced8 cards · 4 qnot started

Wiring beans together: constructor injection, stereotype annotations, choosing between two candidates, and @Bean methods.

Intermediate to Advanced7 cards · 5 qnot started

Dependency injection: why a class should be handed its dependencies instead of creating them, shown without Spring first.

Beginner5 cards · 4 qnot started

Choosing a creational design pattern: telling Factory Method, Abstract Factory, Builder, Prototype and Singleton apart, and when a plain constructor is enough.

Intermediate to Advanced5 cards · 4 qnot started

Choosing a structural design pattern: telling Adapter, Decorator, Facade, Proxy, Composite, Bridge and Flyweight apart by what each wrapper is for.

Intermediate to Advanced5 cards · 4 qnot started

Choosing a behavioural design pattern: telling Strategy, State, Template Method, Command, Observer, Mediator, Chain of Responsibility and Decorator apart by who decides and how many objects take part.

Intermediate to Advanced5 cards · 5 qnot started

The Java Collections Framework: List, Set and Queue, what each promises, and which type to declare a variable with.

Intermediate to Advanced8 cards · 5 qnot started

Java Optional: a return type that puts possible absence in the signature, how to unwrap it, and where it does not belong.

Intermediate to Advanced8 cards · 5 qnot started

Java polymorphism: how the runtime object chooses which overridden method runs, what the declared type decides, hiding, casts and instanceof.

Intermediate to Advanced9 cards · 5 qnot started

Java interfaces and abstract classes: naming a capability, sharing state, default methods, and choosing between the two.

Intermediate to Advanced8 cards · 5 qnot started

Java encapsulation: private fields, the four access levels, references that leak through getters and constructors, and composition against inheritance.

Intermediate to Advanced8 cards · 5 qnot started

Sorting your own types in Java: Comparable for the natural order, Comparator for the rest, and the two ways a comparator goes wrong.

Intermediate to Advanced9 cards · 5 qnot started

The Factory Method pattern: letting subclasses decide which class of object to create, so the code that uses the object never names it.

Intermediate to Advanced9 cards · 4 qnot started

The Builder pattern: constructing a complex object step by step, so a constructor with a dozen optional parameters is never needed.

Intermediate to Advanced9 cards · 4 qnot started

The Singleton pattern: guaranteeing a class has exactly one instance with a global access point, and why it is the most criticised of the 23.

Intermediate to Advanced9 cards · 4 qnot started

The Proxy pattern: a stand-in with the same interface as a real object that controls when and whether calls reach it, and the self-call it never sees.

Intermediate to Advanced9 cards · 4 qnot started

The Strategy pattern: putting each interchangeable algorithm behind one interface so the caller chooses it, and why in Python the strategy is often a function.

Intermediate to Advanced9 cards · 4 qnot started

The Observer pattern: letting many objects subscribe to one and be told when it changes, and the listener that is never unsubscribed.

Intermediate to Advanced9 cards · 4 qnot started

The Command pattern: turning a request into an object that can be queued, logged or undone, and what each command must remember to undo itself.

Intermediate to Advanced9 cards · 4 qnot started

The Template Method pattern: fixing the order of an algorithm's steps in a base class and letting subclasses supply the steps that differ.

Intermediate to Advanced9 cards · 4 qnot started

The Iterator pattern: walking a collection one element at a time without knowing how it is stored, and why a Python generator can be walked only once.

Intermediate to Advanced9 cards · 4 qnot started

The Visitor pattern: adding operations over a fixed set of classes as separate visitor classes, how double dispatch finds the right method, and why a new element class is costly.

Intermediate to Advanced9 cards · 4 qnot started

Applying the SOLID principles together: diagnosing a class that breaks several, refactoring it safely behind tests, and knowing when to stop.

Intermediate to Advanced7 cards · 5 qnot started

What design patterns are: named, reusable solutions to recurring object-oriented design problems, how the 23 classic ones are grouped, and when one costs more than it saves.

Beginner to Intermediate8 cards · 5 qnot started

Reading UML class diagrams: the boxes, lines and arrowheads every design pattern is drawn with, and how each relationship looks in code.

Beginner to Intermediate8 cards · 5 qnot started

The Abstract Factory pattern: creating whole families of related objects through one interface, so a program can switch every product at once.

Intermediate to Advanced8 cards · 4 qnot started

The Prototype pattern: creating new objects by copying a configured one, and the shallow copy trap that comes with it.

Intermediate to Advanced8 cards · 4 qnot started

The Adapter pattern: wrapping an existing class so it fits the interface a client already expects, without changing either side.

Intermediate to Advanced8 cards · 4 qnot started

The Decorator pattern: adding behaviour to an object by wrapping it in others with the same interface, and how it differs from Python's @ syntax.

Intermediate to Advanced8 cards · 5 qnot started

The Facade pattern: one simple interface in front of a complex subsystem, with the subsystem's classes still there for the cases the facade does not cover.

Intermediate to Advanced8 cards · 4 qnot started

The Composite pattern: treating a single object and a group of objects the same way, as in files and folders.

Intermediate to Advanced8 cards · 4 qnot started

The Bridge pattern: splitting what something is from how it is done into two hierarchies, so they grow without multiplying classes.

Intermediate to Advanced8 cards · 4 qnot started

The Flyweight pattern: sharing the common part of many small objects so that a program holding millions of them still fits in memory.

Intermediate to Advanced8 cards · 4 qnot started

The State pattern: giving each state of an object its own class, so behaviour changes when the state changes, and deciding which class chooses the next state.

Intermediate to Advanced8 cards · 4 qnot started

The Chain of Responsibility pattern: passing a request along a chain of handlers until one deals with it, and ending every chain with an answer for requests nobody accepts.

Intermediate to Advanced8 cards · 4 qnot started

The Mediator pattern: routing the communication between many objects through one coordinator, and counting the links it removes.

Intermediate to Advanced8 cards · 4 qnot started

The Memento pattern: saving an object's state as a snapshot only that object can read, so it can be restored later, and keeping the snapshots from filling the memory.

Intermediate to Advanced8 cards · 4 qnot started

The Interpreter pattern: representing each rule of a small language as a class, evaluating a sentence as a tree of those objects, and knowing that parsing is a separate job.

Intermediate to Advanced8 cards · 4 qnot started

Choosing a creational design pattern: telling Factory Method, Abstract Factory, Builder, Prototype and Singleton apart, and when a plain constructor is enough.

Intermediate to Advanced5 cards · 4 qnot started

Choosing a structural design pattern: telling Adapter, Decorator, Facade, Proxy, Composite, Bridge and Flyweight apart by what each wrapper is for.

Intermediate to Advanced5 cards · 4 qnot started

Choosing a behavioural design pattern: telling Strategy, State, Template Method, Command, Observer, Mediator, Chain of Responsibility and Decorator apart by who decides and how many objects take part.

Intermediate to Advanced5 cards · 5 qnot started

Authenticating API clients: API keys, sessions, bearer tokens, JWTs and mutual TLS, and which one suits each kind of caller.

Beginner to Advanced12 cards · 8 qnot started

The building blocks of a web system: DNS, CDNs, application servers and databases, and the path a request takes through them.

Beginner to Intermediate11 cards · 8 qnot started

REST and resource design: naming the things an API exposes and the paths that reach them, with filtering, sorting and actions that are not plain updates.

Beginner to Advanced11 cards · 7 qnot started

HTTP caching for APIs: telling clients and CDNs how long to keep a response, and using ETags to skip unchanged downloads and to stop two clients overwriting each other.

Beginner to Advanced11 cards · 8 qnot started

Load balancers, reverse proxies and API gateways: the three kinds of server that sit in front of yours, and the one job each is for.

Beginner to Intermediate10 cards · 5 qnot started

Client-server communication: polling, server-sent events, WebSockets and webhooks, chosen by who sends and how often.

Beginner to Intermediate10 cards · 5 qnot started

Software architectural styles: monoliths, layers, microservices, events and serverless, and the team and product each one fits.

Beginner to Advanced10 cards · 5 qnot started

How WebSocket, server-sent events and WebRTC keep a connection open, who may send on it, and how each one survives a drop.

Beginner to Advanced10 cards · 6 qnot started

HTTP methods for APIs: what GET, POST, PUT, PATCH and DELETE promise, and which are safe to repeat.

Beginner to Intermediate10 cards · 7 qnot started

API contracts: the fields, types and formats a client and server agree on, written down so machines can check them.

Beginner to Advanced10 cards · 7 qnot started

Protecting an API: the common API security risks, object-level checks, rate limits a client can act on, and what CORS does and does not do.

Beginner to Advanced10 cards · 8 qnot started

Requirements and trade-offs: deciding what a system must do and how well, so a design has something to be checked against.

Beginner to Intermediate9 cards · 5 qnot started

Caching: keeping copies of frequent reads close, deciding when they go stale, and the ways a cache can take a system down.

Beginner to Advanced9 cards · 8 qnot started

Scaling a web system up or out: bigger machines or more of them, what has to be stateless first, and what autoscaling cannot catch.

Beginner to Advanced9 cards · 5 qnot started

Message queues and publish/subscribe: handing work off without waiting, and choosing between one reader and many.

Beginner to Intermediate9 cards · 6 qnot started

HTTP status codes for APIs: choosing the code that tells a client what happened and what to do next.

Beginner to Intermediate9 cards · 7 qnot started

Asynchronous APIs: answering a long job with 202 Accepted and a status to check, and sending signed webhooks a receiver can trust.

Beginner to Advanced9 cards · 5 qnot started

Versioning an API: telling breaking changes from safe ones, and retiring an old version without stranding its clients.

Beginner to Advanced9 cards · 6 qnot started

REST, GraphQL and gRPC: what each API style exposes, and how to choose one for an integration.

Beginner to Advanced9 cards · 5 qnot started

Back-of-the-envelope estimation: turning users and their actions into requests a second, storage and downtime, before choosing a single part.

Beginner to Intermediate8 cards · 6 qnot started

API pagination with offsets and cursors: returning large results a page at a time without skipping rows or slowing down.

Beginner to Intermediate8 cards · 5 qnot started

API error responses: one error format a client can branch on, with enough detail to fix the request and nothing an attacker can use.

Beginner to Intermediate8 cards · 5 qnot started

System design heuristics: matching a pressure such as read-heavy traffic or global users to the pattern that answers it.

Intermediate to Advanced7 cards · 5 qnot started

Designing an API end to end: from requirements to reviewed endpoints, errors and a contract for one feature.

Intermediate to Advanced7 cards · 6 qnot started

Caching in Spring Boot: @Cacheable, @CachePut and @CacheEvict, cache keys, caching strategies, and the default provider's limit.

Intermediate to Advanced7 cards · 5 qnot started

Idempotency keys: letting a client retry a payment or an order after a timeout without it happening twice.

Beginner to Advanced6 cards · 4 qnot started

Mapping HTTP requests to controller methods: verbs and paths, reading request data, and choosing the response.

Intermediate to Advanced6 cards · 4 qnot started

Spring Data JDBC vs Spring Data JPA: persistence context, dirty checking, lazy loading, aggregates, and when to choose each.

Intermediate to Advanced7 cards · 4 qnot started