Document author: Mark Evans
Document version: v0.1
Status: Draft
Approved by: …
Date approved: …
Review date: 2025-11-14
Template version: 1.2
| Date | Version | Author | Revision Summary |
|---|---|---|---|
| 2025-11-14 | v0.1 | Mark Evans | Initial draft |
| Committee or Group | Date | Outcome |
|---|---|---|
| … | yyyy-mm-dd | Draft |
The Malware Scanner Service provides asynchronous malware scanning for uploaded documents. Documents are stored in MinIO buckets, and a message is sent to RabbitMQ to trigger scanning by a Java Spring Boot worker. The goal is to provide a reliable, scalable, isolated malware‑scanning process that integrates cleanly with surrounding systems.
- Accept file-upload notifications
- Retrieve file objects for scanning
- Scan files for malware
- Emit clean/infected results
- Quarantine infected files
- Operate asynchronously and at scale
- Reliability: Messages must not be lost; scans must complete.
- Scalability: Multiple workers must run in parallel.
- Security: Isolation during scanning; secure access to buckets and queues.
- Observability: Metrics and logs for throughput, failures, and performance.
| Role/Name | Contact | Expectations |
|---|---|---|
| Solution Architect | … | Accurate architecture documentation |
| DevOps / Platform Team | … | Clarity on deployment, scaling, and ops |
| Security Team | … | Clear visibility of scanning and quarantine flows |
| Integrating Services | … | Clear API/queue contract and flow |
- Must use cloud object storage.
- Must use a queue for asynchronous job triggering.
- Must run as containerized Spring Boot service.
- Must not access external internet during scanning.
- Must support horizontal scaling.
The system sits between file‑uploading applications and consuming downstream services. It does not handle direct file uploads; it reacts to messages indicating a file has been uploaded to MinIO.
- Upstream systems store documents in MinIO and notify the scanner.
- The scanner determines malware risk and publishes results.
- Downstream systems use scan results for triage, acceptance, or rejection.
- Event‑driven asynchronous processing via RabbitMQ.
- Blob storage in MinIO; documents referenced by bucket/key.
- Spring Boot application performing scanning and publishing results.
- Optional ClamAV or compatible engine for scanning.
- C4 model used for decomposition.
Representative workflow:
- Event‑driven architecture
- Worker‑queue consumer pattern
- Adapter pattern for plugging different malware engines
- TLS for RabbitMQ
- IAM‑style scoped credentials for MinIO
- Strict container isolation for scanning engine
- Horizontal pod autoscaling for scanner workers
- RabbitMQ consumer scaling
- MinIO bucket partitioning
- Retry and DLQ in RabbitMQ
- Idempotent scan operations
- Prometheus metrics
- Structured JSON logging
- Trace IDs from incoming messages
- Malware scanning supports IG controls on unsafe attachments
- Audit logs retained according to organisational policy
| ID | Impact |
|---|---|
| ADR‑001 | Select RabbitMQ for asynchronous messaging |
| ADR‑002 | Use MinIO for object storage |
| ADR‑003 | Use Spring Boot for worker service |
| Date | Impact | Rationale |
|---|---|---|
| yyyy-mm-dd | Introduced MinIO | Required S3‑compatible local storage |
- Low false‑positive rate
- High throughput under load
- Secure isolation of untrusted files
- Compatibility across environments
| ID | Impact | Mitigation / Plan | Owner |
|---|---|---|---|
| R1 | Medium | Add DLQ monitoring | … |
| R2 | High | Sandbox scan-engine | … |
| ID | Impact | Mitigation / Plan | Owner |
|---|---|---|---|
| TD1 | Medium | Replace tightly-coupled scanner code | … |
| Term | Definition |
|---|---|
| MinIO | S3-compatible object storage |
| RabbitMQ | AMQP message broker |
| Malware Engine | Component responsible for scanning files |