Integrations that survive change
REST is an architectural style. SOAP is a messaging protocol. Both can be integrated without contaminating the domain when contracts, errors, and effects stay behind explicit adapters.
Isolate external contracts from the domain
- REST / SOAPauth · contracts · errors
- Adaptersmapping · timeout · retry
- Domaintransport-free rules
- Outboxatomicity · idempotency
- PostgreSQLtables · indexes · partitions
- Operationsquery plans · bloat · autovacuum
Explicit contracts and failures
REST and SOAP are not exact equivalents, but share operational risks: authentication, timeouts, partial responses, and contract changes. An adapter translates transport and errors into domain concepts.
- Contract tests over real examples.
- Timeouts and retries only for safe operations.
- Idempotency keys or deduplication for commands.
- Circuit breaking only when it protects the system.
PostgreSQL: measure before splitting
Partitioning helps when access and maintenance patterns can prune partitions; it also adds objects and complexity. Indexes speed reads at the cost of space and writes. Decisions begin with data and a query plan.
- EXPLAIN (ANALYZE, BUFFERS) in a safe environment.
- Indexes aligned with filters, joins, and ordering.
- Range, list, or hash partitioning only around a stable key.
- Sharding or distribution only after one measured node is insufficient.
Bloat and autovacuum are normal operations
Updates and deletes leave dead tuples. Autovacuum recovers reusable space and maintains statistics; its settings must be observed per table. Diagnose bloat with evidence rather than vague fragmentation language.
- Transaction age and wraparound risk.
- Dead tuples, vacuum frequency, and duration.
- Table and index growth.
- Reindex or rewrite only after measuring cause and impact.