Architecture and Operating Model
Architecture and Operating Model
Section titled “Architecture and Operating Model”The Deals Platform is a role-aware B2C/B2B web application for publishing, browsing, and managing deals.
At a high level, the solution uses:
- a single web application and server runtime
- a PostgreSQL database for business and operational data
- OpenID Connect for identity
- SMTP for notifications
- a reverse proxy and TLS termination layer in the reference deployment
This keeps the operational shape straightforward: one application runtime, one primary database, one identity integration, one email integration, and one public ingress layer.
High-level architecture view showing the browser, reverse proxy, application runtime, data store, and external enterprise integrations.
Architecture
Section titled “Architecture”The current implementation is based on Node.js, Nuxt, Prisma, Caddy, and PostgreSQL in the reference deployment model. Prisma as a technology supports other database engines, but the current platform is built and documented around PostgreSQL.
The reference solution is built around these relationships:
- end users access the platform through a web browser
- traffic enters through a reverse proxy and TLS layer
- the application runtime serves the UI and API
- PostgreSQL stores business, operational, and audit-related records
- the application integrates with an external identity provider through OpenID Connect
- the application integrates with an SMTP service for notifications
This shape is well suited to customer-controlled hosting because the dependency chain is easy to reason about and does not require a large internal platform team to operate.
Operations Model
Section titled “Operations Model”The implementation supports both host-based and container-based deployment patterns, with the same core application model behind them.
From an IT planning perspective, the important decisions are typically:
- where the application runtime is hosted
- where the database is hosted
- which identity provider is trusted
- which SMTP service is used
- how TLS certificates and DNS are managed
Most environments would plan for the following enterprise dependencies:
- DNS and hostname management
- TLS certificates and certificate trust
- PostgreSQL hosting and backup policy
- OpenID Connect identity provider such as Google or Microsoft
- SMTP service for transactional notifications
- monitoring, alerting, and log retention in line with local policy
Security And Compliance Snapshot
Section titled “Security And Compliance Snapshot”| Topic | Position |
|---|---|
| Hosting model | The platform can be deployed in customer-controlled infrastructure with customer-selected identity, database, certificate, and email services. |
| Authentication | The platform uses OpenID Connect rather than a separate local username and password store. |
| Role control | The current platform supports customer and seller roles. Seller role assignment currently uses an approved email allowlist. |
| Web application security | The platform aligns with OWASP-oriented web application security practices, including secure session handling, role-based access control, request validation, CSRF protection, rate limiting, HTTPS-oriented deployment, and security headers. |
| Data stored | The platform stores deal data plus operational records such as user email, role, offers, favorites, subscriptions, audit history, session state, rate-limit state, and email delivery state. |
| Auditability | Core business actions are audit-capable, supporting traceability for deal lifecycle activity and other important operational events. |
| Transport security | The reference deployment model is TLS-oriented and supports certificate-aware integration with identity, database, and SMTP services. |
| GDPR position | The platform supports GDPR-oriented deployment through identity-based access control, minimized local credential handling, auditability, and cleanup of selected operational records. |
| NIS2 position | The platform supports NIS2-relevant deployment expectations such as controlled ingress, central identity integration, secure transport, auditability, and application-layer protective controls. |
| Formal compliance claim | This page should not be read as a legal certification or universal compliance guarantee. Final policy, retention, governance, and operational control mapping remain part of implementation planning. |
Browser Support Policy
Section titled “Browser Support Policy”The application is designed for modern evergreen browsers on both desktop and mobile.
- Google Chrome, Microsoft Edge, Mozilla Firefox, and Chrome for Android: latest stable release and the previous 4 major versions
- Safari on supported macOS, iPhone, and iPad releases: current stable Apple browser line
We provide best-effort support for:
- Firefox on Android
- Samsung Internet
- older still-maintained Apple browser lines on legacy operating system versions
Topics Usually Finalized During Onboarding
Section titled “Topics Usually Finalized During Onboarding”- target hosting model and environment boundaries
- identity-provider setup and access policy alignment
- certificate and trust-chain planning
- backup, restore, and disaster-recovery expectations
- logging, alerting, and support responsibilities
- customer-specific security and compliance control mapping