Architecture notes
Decisions, boundaries, and the cost of each.
Each note is labeled. Personal experience is limited to verified roles. Technical perspective is general engineering judgment, not a claim about a specific production system.
Designing scalable microservices
Service boundaries are a cost. Scale the ones the domain actually needs; keep the rest as a modular monolith until the seam is real.
Read note →
Event-driven architectures
Events decouple writers from readers. They also hide the call graph. Use them when the domain is already a sequence of facts, not to avoid an API.
Read note →
RabbitMQ consumer scaling
Throughput comes from prefetch, ack strategy, and partition-like routing keys — not from adding consumers that contend on the same unacked set.
Read note →
Domain-Driven Design
DDD is a way to keep the language of the business inside the code. It is not a catalog of tactical patterns to sprinkle on a CRUD app.
Read note →
Hexagonal Architecture
Ports and adapters are a rule about the direction of dependencies. The domain does not know HTTP, SQL, or the message broker.
Read note →
High-throughput data processing
Throughput is a pipeline problem: batching, backpressure, idempotency, and a store that can accept the write pattern you actually have.
Read note →
API Gateway architecture
A gateway is an edge: auth, routing, and coarse aggregation. It should not become the place where business rules hide.
Read note →
Cloud infrastructure
Cloud is a set of failure domains and managed primitives. Treat it as operations, not as a logo on an architecture slide.
Read note →
Kubernetes
Kubernetes schedules processes. It does not define your bounded contexts, your data model, or your on-call rotation.
Read note →
Performance engineering
Performance is a measurement discipline. Change the bottleneck you can show, not the one that is fashionable.
Read note →