Entrada Segura
Microservices Access Control Platform
Overview
Architected and launched a secure, multi-tenant visitor management and access control platform serving both residential condominiums and commercial buildings. The system handles real-time access validation, visitor registration, and physical gate control through IoT integration.
The Challenge
Traditional access control systems were siloed, lacked real-time authorization capabilities, and couldn't scale to multi-tenant scenarios. We needed to build a platform that could:
- Support hierarchical access control (building → unit → resident → visitor)
- Integrate with multiple IoT gate vendors without vendor lock-in
- Provide instant token revocation for security
- Scale to hundreds of buildings with isolated tenant data
- Maintain 24/7 availability for physical security operations
Architectural Decisions & Trade-offs
Decision: Microservices vs Monolith
Choice: FastAPI microservices architecture
Rationale:
- IoT integration required isolated failure domains - gate controller failures couldn't impact visitor registration
- Different scaling needs: real-time access validation needed low latency, visitor management could tolerate higher latency
- Team could work independently on different services (WhatsApp integration, OCR processing, core access control)
Trade-off: Increased operational complexity (distributed tracing, inter-service communication) for better resilience and scalability.
Decision: PostgreSQL ltree for Authorization
Choice: PostgreSQL with ltree extension for hierarchical tokens
Rationale:
- Access control is inherently hierarchical: Building → Tower → Unit → Resident
- ltree enables efficient ancestor/descendant queries (O(log n)) for permission checks
- Single source of truth for authorization reduces sync complexity
- ACID guarantees critical for security-sensitive access decisions
Alternative Considered: MongoDB with embedded documents - rejected due to lack of efficient hierarchical queries and weaker consistency guarantees for security operations.
Decision: Asynchronous Communication (Celery + RabbitMQ)
Choice: Celery task queue with RabbitMQ broker
Rationale:
- WhatsApp message delivery doesn't require synchronous response - better UX to return immediately
- OCR selfie processing takes 2-3 seconds - can't block HTTP request
- Gate events need to be processed even if upstream services are temporarily down
Result: Average API response time reduced from 3.2s to 180ms. Gate operations remain functional even during WhatsApp API outages.
Technical Implementation
Tech Stack
Key Features Delivered
- Real-time IoT Gate Integration: Multi-vendor gate controller support with immediate token validation and revocation
- WhatsApp Automation: Automated visitor notifications and boarding pass distribution via WhatsApp Business API
- OCR Selfie Processing: Identity verification through document OCR and selfie comparison
- Distributed Tracing: OpenTelemetry + Grafana stack for troubleshooting cross-service requests
- CI/CD Automation: GitHub Actions pipelines across 4 microservice repositories with automated testing and Kubernetes deployment
DevOps & Reliability
- Containerization: Dockerized all services for consistent deployments across dev, staging, and production
- Orchestration: Kubernetes for auto-scaling during peak hours (morning/evening gate access surges)
- Observability: OpenTelemetry for distributed tracing, custom Grafana dashboards for SLA monitoring
- Incident Response: Automated alerts for gate controller disconnections, authorization failures, and service degradation
Impact & Results
Lessons Learned
- Observability from Day 1: Adding OpenTelemetry after production incidents was painful. Should have instrumented services before launch.
- IoT Integration Complexity: Gate vendors have inconsistent APIs. Building an adapter layer upfront saved significant refactoring later.
- Database Choice Matters: PostgreSQL ltree made hierarchical queries trivial. Alternative approaches (application-layer recursion, graph databases) would have been more complex.