Hosting and cost analysis
This document outlines the hosting architecture, free tier limits, and scaling recommendations for the Billettsalg application.
Quick Reference — $0/month
| Service | Tier | Monthly Cost |
|---|---|---|
| Azure Static Web Apps | Free | $0 |
| Azure Functions | Consumption (1M free) | $0 |
| Azure Cosmos DB | Free tier (1000 RU/s) | $0 |
| Resend | Free, current beta volume | $0 |
| Log Analytics | PerGB2018, beta volume | $0 |
| Application Insights | Workspace-based, capped | $0 |
| Total | $0 |
The entire stack can run at zero cost at current beta volume while usage remains within current Azure and Resend free allowances. Application Insights has a 0.1 GB/day ingestion cap, and the initial production verification measured about 12.6 MB over 24 hours. Provider limits and prices can change, so verify them before budgeting.
Current Architecture
| Service | Purpose | Tier |
|---|---|---|
| Azure Static Web Apps | Frontend hosting + API routing | Free |
| Azure Functions (Consumption) | Backend API | Consumption (pay-per-use) |
| Azure Cosmos DB | Database | Serverless / Provisioned |
| Resend | Magic link and invitation emails | Free or paid email plan |
| Log Analytics | Production log storage | PerGB2018 |
| Application Insights | API telemetry and alerts | Workspace-based |
Free Tier Limits
Azure Static Web Apps (Free)
- Bandwidth: 100 GB/month
- Storage: 0.5 GB
- Custom domains: 2
- SSL certificates: Included
- Staging environments: 3
Azure Functions (Consumption Plan)
- Executions: 1,000,000 per month
- Compute: 400,000 GB-seconds per month
- Execution timeout: 10 minutes max
Azure Cosmos DB (Serverless)
- Request Units: Pay per request (~$0.25 per million RUs)
- Storage: $0.25/GB/month
- Free tier option: 1000 RU/s + 25 GB free (provisioned mode)
Resend transactional email
- Current Free plan: 3,000 transactional emails per month
- Current daily limit on Free: 100 emails
- Paid plans: Available when monthly volume or daily peaks exceed the free limits
Check Resend pricing for current limits and prices. The application uses Resend in production. When RESEND_API_KEY is absent, development behavior logs only masked recipient, subject, and sender metadata. Guarded devLink and devCode response fields are available only in E2E test mode.
Azure Monitor
- Workspace telemetry retention: 31 days for Application Insights data stored in the linked Log Analytics workspace
- Daily ingestion cap: 0.1 GB, approximately 100 MB
- Early warning: 80 MB over 24 hours
- Routine telemetry: sampled at up to five items per second per function instance
- Frontend telemetry: no separate browser SDK
Scaling Scenarios
Scenario: 1,500 Users
| Service | Impact | Risk Level |
|---|---|---|
| Static Web Apps | 100 GB bandwidth easily sufficient | ✅ Low |
| Azure Functions | Well within 1M executions | ✅ Low |
| Cosmos DB | May hit 1000 RU/s during peak ordering | ⚠️ Medium |
| ~3000-4500 emails/month for logins | ⚠️ Low-Medium |
Cosmos DB Consideration
With 1,500 users across multiple organizations:
- Storage: Efficient data model (~1-2 GB total). ✅
- Throughput: 1000 RU/s shared across all operations.
Risk scenario: 200+ members ordering tickets in a 30-minute window before deadline could cause rate limiting (HTTP 429 errors).
Email Volume Estimate
- 1,500 users × 2-3 logins/month = 3,000-4,500 emails/month
- The lower end reaches the current Free monthly allowance.
- The upper end exceeds the current Free monthly allowance, and concentrated login days can also exceed the daily limit.
- A paid Resend plan may be required. Check current provider pricing instead of relying on a fixed per-email estimate.
Recommendations
Stay on Free Tier When:
- Users are distributed across multiple choirs
- Ticket ordering is gradual over days (not last-minute rush)
- Occasional slowdowns during peaks are acceptable
Consider paid capacity when:
- Consistent performance during high-traffic periods is important
- Multiple large organizations use the system simultaneously
- You need provider features or capacity beyond the free allowances
Example paid configuration
| Service | Configuration | Cost guidance |
|---|---|---|
| Cosmos DB | Autoscale or higher provisioned throughput | Use the Azure Cosmos DB pricing page or calculator |
| Static Web Apps | Stay on Free if its limits remain sufficient | $0 within current Free limits |
| Functions | Stay on Consumption if its allowance remains sufficient | Usage-based beyond the allowance |
| Resend | Select a plan for actual monthly volume and daily peaks | Use current Resend pricing |
Do not treat this example as a quote. Region, traffic shape, provider changes, and selected features affect the final cost.
Optimization Strategies (Free Tier)
If staying on free tier, consider these optimizations:
1. Caching
- Cache frequently accessed data (events, ticket types)
- Use localStorage for user session data
2. Batch Operations
- Aggregate multiple small writes into fewer operations
- Use bulk operations where possible
3. Spread Load
- Set order deadlines at off-peak times (e.g., 2pm instead of midnight)
- Send reminder emails in batches throughout the day
4. Efficient Queries
- Always query by partition key (
organizationId) - Avoid cross-partition queries
- Use projections to return only needed fields
Monitoring
The production deployment includes four enabled Portal-only alert rules:
- More than five failed requests in five minutes
- More than ten exceptions in 15 minutes
- More than three failed dependencies in five minutes
- More than 80 MB of billable ingestion over 24 hours
No action groups are attached. Review alerts in Azure Monitor and continue watching Cosmos DB request units, API response latency, Function failures, and email delivery.
The ingestion cap controls monitoring volume, not application traffic. If telemetry reaches the cap, monitoring can become incomplete until the cap resets, but the application continues to process requests.
Planning signals by user count
User count alone does not determine cost. Login frequency, ordering peaks, telemetry volume, and Cosmos DB request units are stronger signals.
| Users | Email planning signal | Database planning signal |
|---|---|---|
| 100-500 | Usually compatible with low-volume use, subject to the daily limit | Usually compatible with the current free allocation |
| 1,000 | Monitor daily sign-in peaks and monthly email totals | Monitor request units during ordering windows |
| 1,500 | The example above can exceed the current Resend Free allowance | Peak ordering can cause throttling |
| 3,000+ | Plan and budget from current Resend pricing | Model request units and evaluate paid throughput |
Recalculate from measured production usage before changing a plan.
When to Scale
Immediate action needed if:
- Users report consistent slow responses
- Cosmos DB metrics show frequent 429 (rate limit) errors
- Email delivery starts failing regularly
Plan ahead when:
- Adding new large organizations (100+ members each)
- Approaching major concert seasons
- User growth exceeds 2,000 active users
See also: Azure Deployment · Architecture