Software architecture
Choose system boundaries, compare architectural tradeoffs, and evolve an application without unnecessary complexity.
Showing 1–10 of 10 articles
Plan a reversible release for a risky architectural change
Release architectural changes through compatible stages, bounded exposure, measurable checkpoints, and a recovery plan that includes data and side effects.
Review an AI proposed architecture against actual requirements
Evaluate an AI architecture proposal against real requirements, ownership, failure modes, and operating costs before adopting its services or abstractions.
Design tenant isolation into every data access path
Carry trusted tenant context through queries, caches, jobs, files, and administration, then verify isolation with cross-organization negative tests.
Find a scaling bottleneck before splitting the application
Measure latency, resource saturation, and workload shape before splitting services, then compare bounded fixes against the actual limiting resource.
Use an outbox when database success and message delivery diverge
Close the gap between committed business data and failed message delivery with an outbox, repeatable dispatch, and consumer duplicate protection.
Design a background job for work that should not block a request
Move slow work into durable background jobs with clear acceptance, bounded retries, duplicate protection, cancellation, and visible recovery states.
Separate domain rules from framework plumbing without overengineering
Keep business decisions separate from HTTP and database plumbing with a small function boundary, explicit inputs, and behavior-focused verification.
Write an architecture decision that explains the tradeoff
Write a concise architecture decision with concrete constraints, credible alternatives, accepted costs, and evidence that would trigger a review.
Draw a system boundary from one real user journey
Trace one user outcome across UI, authorization, storage, and providers to draw a useful system boundary with explicit ownership and failure states.
Choose a modular monolith before reaching for microservices
Compare deployment, ownership, and failure boundaries before choosing microservices, then build module boundaries you can verify inside one application.
Explore topics
Subscribe to Newsletter
Get the latest articles and updates delivered to your inbox.