Questions to ask your professor about overall system design, integration, and evaluation criteria.
Q: Should we add authentication/encryption to MQTT messages, or is it acceptable to keep it unencrypted for this academic project?
Context: Currently, MQTT messages are sent in plaintext without authentication. In production, we'd use MQTTS (TLS encryption) and username/password auth.
Why it matters: Security vs complexity trade-off for academic demonstration.
Q: We're using both REST APIs and MQTT - is this the right balance, or should we standardize on one protocol?
Context:
- REST: Control, configuration, queries (request/response)
- MQTT: Real-time data streaming, alerts (publish/subscribe)
Why it matters: Determines if we should refactor communication patterns.
Q: What level of error handling do you expect? Should we implement retry mechanisms and circuit breakers, or is basic try-catch sufficient?
Context: Currently using try-catch blocks. Could add:
- Exponential backoff retries
- Circuit breakers for failing services
- Graceful degradation
Why it matters: Affects system resilience and code complexity.
Q: How should we handle cascading failures? For example, if TimeSeries DB is down, should Analytics degrade gracefully or fail completely?
Current behavior: Services return errors when dependencies unavailable.
Alternatives:
- Cache last-known data
- Operate in degraded mode
- Queue requests for retry
Q: What scale should we design for? Current system handles 3-4 pipelines - should we prove it works for 100+, or is the current scale acceptable?
Current capacity: 3-4 pipelines, ~12 sensors, 1 sensor reading/second
Implications:
- Database sizing
- Message queue throughput
- API response times
- Resource requirements
Q: Should we implement integration tests?
Current state: No automated tests
Options:
- Unit tests per service
- Integration tests across services
- End-to-end workflow tests
- Load/stress testing
Q: How should we demonstrate system resilience?
Possible demonstrations:
- Kill services and show auto-recovery
- Simulate sensor failures
- Demo emergency shutdown scenarios
- Show graceful degradation
Q: Should we create a dedicated system monitoring dashboard?
Would show:
- Service health status
- Message throughput (msgs/sec)
- API latency metrics
- Database size/growth
- MQTT queue depth
Alternative: Main dashboard shows basic health indicators (current implementation)
Q: What metrics should we collect to evaluate system performance?
Suggested metrics:
- Latency: Sensor reading → Analytics → Control action
- Throughput: Messages/second processed
- Accuracy: Anomaly detection precision/recall
- Availability: Service uptime percentage
- Reliability: Message delivery rate
Q: Should we implement performance benchmarking?
Tests:
- Load testing (10/100/1000 pipelines)
- Response time measurements
- Database growth over time
- Memory/CPU usage
Or focus on functional correctness?
Q: What aspects of the project will be weighted most heavily in grading?
Possible factors:
- Architecture design
- Implementation quality
- Code documentation
- System documentation
- Presentation quality
- Innovation/creativity
- Completeness
Why it matters: Helps prioritize remaining work.
Q: Should we prioritize breadth (more features) vs depth (robust implementation)?
Breadth: Add more features (ML analytics, mobile app, advanced visualizations)
Depth: Improve existing features (better error handling, comprehensive testing, performance optimization)
Q: Are there specific IoT concepts you want us to demonstrate?
Current concepts:
- Real-time data streaming (MQTT)
- Time-series data storage
- Edge simulation (Raspberry Pi)
- Anomaly detection
- Automated control systems
- Service-oriented architecture
Additional concepts:
- Edge computing
- Data aggregation strategies
- Predictive maintenance
- Digital twins
Q: Should we prepare a live demo or video demonstration?
Live demo:
- ✅ Shows real-time capabilities
- ✅ Interactive Q&A
- ❌ Technical issues risk
- ❌ Time pressure
Video demo:
- ✅ Polished presentation
- ✅ Can re-record if needed
- ❌ Less interactive
- ❌ Doesn't show live system
Both?
Q: What documentation format do you prefer?
Options:
- Technical report (PDF)
- README files (Markdown)
- API documentation (Swagger/OpenAPI)
- Architecture diagrams (UML, C4)
- Code comments (inline)
- Video walkthrough
Current: README + Architecture diagrams
Q: Should we containerize services with Docker?
Current: Local Python execution with Makefile
Docker benefits:
- Isolated environments
- Easier deployment
- Reproducible setup
- Platform independence
Docker drawbacks:
- Additional complexity
- Learning curve
- Resource overhead
Q: Do you want us to deploy to cloud or is local demonstration sufficient?
Cloud options:
- AWS (EC2, IoT Core, TimeStream)
- Azure (IoT Hub, Time Series Insights)
- GCP (Cloud IoT, Bigtable)
Benefits: Shows production-ready deployment
Drawbacks: Cost, complexity, time
Q: Should we implement CI/CD pipeline?
Could implement:
- GitHub Actions for automated testing
- Automated deployment
- Code quality checks (linting, formatting)
- Dependency updates
Priority for this project?
Q: How should we handle time zones?
Current: UTC timestamps everywhere
Options:
- Convert to local time in UI
- Support multiple time zones
- User-configurable time zone preference
Q: Should we implement data export functionality?
Features:
- Export sensor data (CSV, JSON, Excel)
- Generate PDF reports
- Historical data download
- Analytics results export
Priority?
If you only have time for a few questions, ask these first:
- What's the expected scale and complexity for this project? (Sets scope)
- What specific IoT concepts do you want demonstrated? (Guides focus)
- Should we prioritize new features or robustness of existing ones? (Development strategy)
- What level of testing/documentation is expected? (Quality bar)
- Live demo or pre-recorded, and what should we emphasize in presentation? (Delivery format)
Use these questions to:
- Guide remaining development work
- Understand evaluation criteria
- Prioritize features vs polish
- Prepare effective demonstration
- Align with professor's expectations