14 articles tagged with "architecture"
Your database commit succeeded. Your Kafka publish failed. Now what? The transactional outbox pattern fixes the dual-write problem that every 'just publish an event after saving' tutorial conveniently skips.
DELETE FROM users WHERE id = 42 feels satisfying right up until legal, support, and future-you all ask where that row went. A field guide to soft deletes, hard deletes, and the audit tables that actually save you.
Hexagonal architecture sounds like a whiteboard fantasy until the day your team swaps Postgres for DynamoDB in an afternoon. A skeptic's guide to ports, adapters, and why the hexagon isn't the point.
Shared schema, schema-per-tenant, or database-per-tenant? A practical tour of multi-tenancy strategies, the tradeoffs nobody puts on the slide, and the row-level security trick that saves you from your own ORM.
You can't BEGIN/COMMIT across five microservices. The saga pattern is how you fake it anyway — with compensations instead of rollbacks and a lot of humility about what \"consistent\" actually means.
You write to the database, then publish an event. What happens when the process dies between those two lines? The outbox pattern is the boring, reliable answer to a problem every event-driven system eventually hits.
Your monolith had ROLLBACK. Your microservices don't. The saga pattern is how you fake a distributed transaction using nothing but events, compensating actions, and the quiet acceptance that everything is eventually consistent.
The classic test pyramid assumes one codebase, one deploy, one team. Split that into fifteen services and the shape quietly stops making sense. Here's what actually works when 'integration' means 'a network call to someone else's team.'
Most databases only store the current state — the last write wins and history vanishes. Event Sourcing flips this on its head: store what happened, derive what is. Here's how to apply it without drowning in ceremony.
CQRS separates the commands that mutate state from the queries that read it — giving you independent scaling, specialized models, and saner codebases. Here's when it's worth the complexity and when it's overkill.
Your API endpoint shouldn't be sending emails, resizing images, AND returning a response in 200ms. Meet job queues — the background workers that do the slow stuff so your API can stay fast.
You shipped a \"small\" API change and now 3 mobile apps are on fire. Sound familiar? Let's talk API versioning in Express — how to evolve your backend without nuking your users.
You've been installing pub/sub libraries while Node.js ships one in the box. Let's fix that — EventEmitter is more powerful than you think.
Sending emails, processing images, generating PDFs — your API shouldn't make users wait for slow work. Job queues are the secret weapon that keeps your responses snappy while the heavy lifting happens in the background.