​

Non-functional requirements

Non-functional requirements define the quality attributes and constraints the platform must satisfy independently of any specific feature. They govern how the system behaves, not what it does.

​

Performance

​

Response time targets

​

Throughput targets

​

Resource utilization

• CPU: average below 70%; peak below 90%.
• Memory: average below 80%; peak below 95%.
• Disk I/O: below 80% during peak hours.

---

​

Security

​

API rate limiting

All API routes enforce throttling at the middleware layer. The limits defined in routes/api.php are: Web routes add targeted throttling on top of this:

• Login form: 5 attempts per minute per IP (brute-force protection).
• Password reset email: 3 requests per 5 minutes.
• Password reset form submission: 5 submissions per minute.
• Payment submission: 10 per minute (double-submission prevention).
• Contact form: 3 per 10 minutes.
• Newsletter subscribe: 5 per 10 minutes.

​

Authentication and session security

• API authentication uses Laravel Sanctum token-based auth. Tokens can be revoked individually (POST /api/v1/auth/logout) or globally (POST /api/v1/auth/logout-all).
• Web sessions use Laravel’s built-in session management with CSRF protection on all state-changing forms.
• Passwords are hashed using Laravel’s hashed cast (bcrypt by default); plain-text passwords are never stored or logged.
• Optional two-factor authentication (2FA) is available for user accounts.
• Social OAuth is supported via Socialite (Google, Facebook) as an alternative to password-based login.

​

KYC and identity verification

• Guides must complete KYC (Know Your Customer) verification before their packages are eligible for publication.
• KYC documents are submitted through a dedicated verification flow at user/verification/kyc.
• An admin reviews documents and approves or rejects the application. Verification status history is retained.
• High-value transactions may require KYC for travelers as well.

​

Data protection

• All data in transit is encrypted via HTTPS.
• Sensitive user attributes (password, remember_token) are excluded from API serialization in User::$hidden.
• The platform targets GDPR compliance: users can export, modify, and delete their personal data.
• Financial records are retained for 7 years in line with regulatory requirements.
• Audit logging covers all sensitive operations and admin actions.
• The system does not store raw payment card data; payment card processing is delegated entirely to gateway providers (PCI DSS compliance).

​

Input validation and injection prevention

• All user inputs are validated and sanitized server-side before processing or storage.
• State-changing web routes use POST (not GET or ANY) to prevent CSRF and accidental invocation via URL.
• Booking transaction IDs are generated using random_bytes(8) (format: BK-XXXXXXXXXXXXXXXX), making them cryptographically random and non-enumerable.

---

​

Reliability

​

Availability

• Target uptime: 99.9% (equivalent to ≤ 8.76 hours downtime per month).
• Scheduled maintenance windows must be under 4 hours per month.
• Disaster recovery time objective (RTO): under 4 hours.
• Automated daily backups with integrity verification.

​

Error handling

• Transaction error rate target: below 1%.
• The system recovers automatically from transient errors (network timeouts, queue failures).
• All errors are logged with sufficient context for diagnosis.
• Users receive clear, actionable error messages rather than raw stack traces.

​

Data integrity

• Critical operations (booking creation, payment processing, payout dispatch) use database transactions with ACID guarantees.
• The bookings table uses ordered UUIDs for public-facing uid values, preventing sequential enumeration.
• Stale unpaid bookings (status 0, older than 5 days) are pruned automatically via the Booking::prunable() method to free capacity.
• Input and output data is validated at the application layer before reaching the database.

---

​

Scalability

​

Horizontal scaling

• Redis handles session storage and cache, allowing multiple application server instances to share state without sticky sessions.
• Queue workers process background jobs (notifications, payout processing, report generation) independently of the web process. Scaling workers horizontally increases throughput.
• AWS S3 (or compatible object storage) is used for file uploads, decoupling storage from the application server.
• A load balancer distributes traffic across application instances.

​

Database scaling

• Read replicas can offload reporting and analytics queries from the primary write database.
• The schema supports sharding by partitioning high-volume tables (bookings, transactions) if needed.

​

CDN

• Static assets and uploaded media are served via a CDN to reduce origin load and improve global delivery latency.

---

​

Accessibility and localization

​

Accessibility

• The platform targets WCAG 2.1 AA compliance.
• All pages support full keyboard navigation.
• UI is compatible with screen reading software.
• Color contrast ratios meet WCAG minimum thresholds.
• Accessible error states are announced to assistive technologies.

​

Localization

• The default language is English; the platform supports at least five additional local African languages via the built-in translation management system.
• Multiple currencies are supported with real-time conversion rates at checkout.
• Timezone handling is correct for all user-facing date and time displays.
• The switch.language route lets users switch the active locale; the preference is stored in the session.

---

​

Maintainability

• Code follows Laravel conventions and established team coding standards.
• Automated test coverage target: 90% for business-critical paths.
• All pull requests require code review before merge.
• Performance monitoring, error alerting, and health checks run continuously in production.
• The system emits metrics suitable for collection by standard APM tooling.