Types of cross-cutting concerns
Concept · Chapter 9
Types of cross-cutting concerns
Section titled “Types of cross-cutting concerns”A non-exhaustive list of common cross-cutting concerns: caching, configuration management, auditing, security, exception management, and logging.
Caching
Section titled “Caching”- Common way to improve performance; used wherever data is read, which makes it cross-cutting.
- A reusable caching service should support: put, get, and expiration policies.
- Two main server-side cache types:
- In-process cache — local to each application instance; load-balanced apps each keep their own.
- Distributed cache — single logical view of the cache across instances on multiple servers.
- Explored further in Server-side caching.
Configuration management
Section titled “Configuration management”- Decide which options are configurable and how config is stored, protected, and modified.
- Keep configuration external to the app so it changes without recompilation, enabling deployment across environments (dev, test, staging, production) and varying services (DB, message broker, SMTP, payment, service registry).
- Aligns with the twelve-factor app’s strict separation of config from code (see Cloud-native applications).
- Make only the necessary settings configurable — excess options add complexity and raise the risk of misconfiguration (breakage or security holes).
- A release is an immutable package (server, VM, or container image) that must deploy to different environments; externalized config provides that flexibility.
- See also Configuration management.
Auditing
Section titled “Auditing”- Maintain an audit trail of data-changing operations: date/time, identity of who changed it, and often old vs. new values.
- In event-driven systems, persisted events and their details can serve as the audit trail.
Security
Section titled “Security”- Includes authentication (verifying identity) and authorization (what operations a user may perform).
- Covered in depth under Securing software systems and Identity and access management (IAM).
Exception management
Section titled “Exception management”- An exception is an expected, recognizable runtime error (null reference, index out of range, timeout, file write failure, DB connection failure).
- Treat as a cross-cutting concern with a centralized, consistent strategy.
- Boilerplate (logging exceptions, notifying the user) should be centralized; never reveal sensitive information in logs or messages; add contextual detail to make logs useful.
- Log all exceptions; plan for unhandled exceptions so failures don’t leave the app unstable or corrupt data.
Logging
Section titled “Logging”Logging shows what code did when it ran — confirming expected behavior and, more importantly, diagnosing problems.
Common log-entry fields: date/time, source/location, log level/severity, message.
Log levels
Section titled “Log levels”| Level | Use |
|---|---|
| TRACE | Fine-grained tracing (method entry/exit) |
| DEBUG | Diagnostic detail during debugging (queries, session info) |
| INFO | Normal-operation details; common default level |
| WARN | Incorrect behavior occurred but the app can continue |
| ERROR | Exceptions/problems that failed an operation |
| FATAL | Most severe errors (shutdown, data corruption) |
- Frameworks let you set a minimum level: e.g. minimum INFO logs INFO, WARN, ERROR, FATAL.
- Verbose levels (TRACE) aren’t sustained in production — high volume degrades performance and consumes disk/bandwidth. Temporarily raising to DEBUG/TRACE is useful while diagnosing.
Routing log entries
Section titled “Routing log entries”- Frameworks route entries by level, source, or a combination, to destinations like console, text files, databases, email, or the Windows Event Log.
- Local text files don’t scale across many servers, and the cloud’s elasticity makes server count and location dynamic.
- Cloud-native apps should treat logs as event streams, writing to stdout/stderr and leaving routing/storage to the environment (see Cloud-native applications).
Elastic Stack
Section titled “Elastic Stack”Formerly the ELK stack — an integrated set of open-source products for aggregating, searching, analyzing, and visualizing log data.
- Elasticsearch — distributed search engine and document store; full-text search, horizontal scaling to billions of log lines, node resilience, condition-based notifications, REST/JSON APIs, many language clients.
- Logstash — log-parsing engine that parses, transforms, filters, enriches, and transports data (e.g. to Elasticsearch); a persistent queue gives at-least-once delivery if a node fails.
- Kibana — Node.js web frontend to explore and visualize Elasticsearch data (dashboards, charts, histograms); shareable via URL, exportable to PDF/CSV.
- Beats — lightweight data shippers: Filebeat (text logs), Metricbeat (metrics), Packetbeat (network), Winlogbeat (Windows events), Auditbeat (audit), Heartbeat (uptime). Libbeat is the shared library for building custom beats. Filebeat is container-ready and coordinates with Logstash to throttle reads under high volume.
Citations
Section titled “Citations”- Software Architect’s Handbook (Packt, 2018), Ch.9 “Types of cross-cutting concerns”, pp. 712-726.