How to build · 08

Software Architecture

SOLID, patterns, clean architecture, monoliths and microservices, events, APIs, caching and multi-tenant SaaS.

Read: 0 / 10Architecture Fundamentals SOLID Design Patterns Clean Architecture Modular Monolith & Microservices Event-Driven & Message Queues API Design Caching Multi-Tenant SaaS System Design

Architecture Fundamentals

Fundamentals✓
Software architecture: what it is and which decisions belong to it
Software architecture is the set of significant decisions about a system that are costly to change: how it is split into modules, where it stores data, which systems it integrates with and how it is deployed. Every such decision is a trade-off between quality attributes: reliability, security, performance, cost and ease of change. Teams show these decisions with diagrams (for example, the C4 model) and record them, with reasons, in ADRs — short documents kept in the repository.
Intermediate · 11 min read

SOLID

Fundamentals✓
SOLID with clear examples
SOLID is five object-oriented design principles collected by Robert C. Martin: Single Responsibility (S), Open/Closed (O), Liskov Substitution (L), Interface Segregation (I) and Dependency Inversion (D). All five answer one question: how to structure code so that a change in one place does not break others and parts can be tested in isolation. They are heuristics, not laws: every abstraction has a cost, so apply a principle where changes actually happen.
Intermediate · 9 min read

Design Patterns

Fundamentals✓
Design patterns you actually need
A design pattern is a named, reusable solution to a recurring design problem: Strategy swaps an algorithm, Adapter translates a foreign API into your interface, Factory creates an object from configuration, Observer delivers events to subscribers, Decorator adds behaviour around a call, Repository hides storage, Builder assembles a complex object step by step. A pattern's value lies in the team's shared vocabulary and in the problem it solves. Without the problem — say, a rule with a single implementation — a pattern only adds code.
Intermediate · 9 min read

Clean Architecture

Deep dive✓
Clean architecture: dependencies point inward, module boundaries
Clean architecture is a way to organize code so that business rules do not depend on the framework, the database or external services. Its central requirement is the dependency rule: source code imports point only inward, from adapters to use cases and entities, and the core talks to the outside world through port interfaces that it declares itself. The TypeScript compiler does not notice violations of this rule, so it is checked by a tool in CI — for example dependency-cruiser or ESLint.
Advanced · 12 min read

Modular Monolith & Microservices

Comparison✓
Modular monolith or microservices
For most new products a sensible start is a modular monolith: one application and one deployment, but modules with a public API, their own data and an automated boundary check. Microservices give independent deployment and team autonomy, but add network calls, eventual consistency and operational complexity — Martin Fowler calls this the “microservice premium”. Extract a service when a module's boundary has settled and its part of the system has gained a separate team or special requirements for scale, availability or security.
Advanced · 12 min read

Event-Driven & Message Queues

Deep dive✓
Event-driven architecture and message queues
Event-driven architecture connects parts of a system with messages: a service records a fact (“order placed”) and publishes an event, and interested services react on their own without blocking the original request. Brokers deliver at least once, so a reliable design rests on two techniques: a transactional outbox, which writes the event to the database in the same transaction as the data, and an idempotent consumer, which recognises a repeat by message id. For external side effects, “exactly once” is only achievable this way: repeats are allowed but do not change the result.
Advanced · 14 min read

API Design

How-to✓
API design: resources, versioning, errors, pagination
A usable API is built around noun resources, uses HTTP methods with the meaning RFC 9110 gives them, answers with precise status codes and Problem Details errors (RFC 9457), pages through large lists with a cursor and evolves without breaking clients. Teams write these conventions into an OpenAPI 3.1 document before coding, check it with a linter and test the implementation against that contract.
Intermediate · 17 min read · practice ~1–2 h

Caching

Deep dive✓
Caching and invalidation
A cache is a copy of data kept closer to its consumer: in the browser, on a CDN, in process memory, in Redis or inside the database. The architectural decisions come down to three questions: which layer holds the copy, how it is filled (cache-aside, read-through, write-through) and how you learn it is outdated (TTL, a change event, a new key version). A separate danger is a cache stampede, when an expired hot key sends hundreds of identical requests to the database at once; a rebuild lock and serving the stale value during the refresh protect against it.
Advanced · 13 min read

Multi-Tenant SaaS

Deep dive✓
Multi-tenant SaaS: isolating tenant data
A multi-tenant SaaS serves many customer tenants from one system, and the core requirement is that one tenant's data is never visible to another. The most economical model is a shared schema with a tenant_id column in every table; in PostgreSQL it is backed by Row-Level Security, where a policy on tenant_id filters rows inside the database even if an application query forgets the condition. Separate schemas or databases per tenant give stronger isolation at an operational cost, and RLS is bypassed by superusers, BYPASSRLS roles and the table owner without FORCE.
Advanced · 14 min read

System Design

Tutorial✓
System design by example: a booking service and scaling it
System design is the path from requirements to architecture where every decision is backed by numbers and constraints. For an online booking service the main bottleneck is not load but correctness: two clients must never get the same time, and the most reliable place for that guarantee is the database, via an EXCLUDE constraint. Notifications through an outbox, a schedule cache, replicas and partitioning are added as the service grows and metrics call for them.
Advanced · 17 min read · practice ~3–6 h

Learning paths with this direction

Java · 6 →Spring Boot · 7 →Software architecture · 9 →APIs and integrations · 8 →← All directions

Tell us about your task — we'll review your request and get back to you

Got a project?
We'll scope and estimate it — for free.

Tell us about the product or the problem. After reviewing the task we'll come back with an architecture, a timeline and a price for the first version.

Scope and risks estimated before we start
NDA — yours or ours
Work starts within a week

Message on WhatsApp