Skip to main content

Engineering Challenges & Lessons Learned

Building FaceLog involved solving several practical engineering problems related to performance constraints, infrastructure limitations, and architectural decisions.

Because the project was developed with limited hardware and no dedicated budget, many technical decisions required creative solutions.

This section documents the main challenges encountered during development and the lessons learned from addressing them.

Real-Time Analysis Performance​

Challenge​

Facial recognition is computationally expensive, especially when processing live camera feeds.

The initial system was deployed on a very modest server, which caused a significant delay in image processing. The face detection stage alone could take up to 10 seconds per frame, making real-time recognition impractical.

This latency severely limited the responsiveness of the system and affected the user experience.

Solution​

Several optimizations were implemented to reduce processing time:

Moving Face Detection to the Frontend​

A lightweight face detection step was introduced in the frontend.

Instead of sending entire frames to the server, the client first detects whether a face is present. Only images containing faces are sent to the backend for recognition.

This significantly reduced unnecessary processing on the server.

Narrowing Backend Responsibilities​

The backend recognition service was simplified to focus primarily on:

  • embedding generation
  • user identification

This reduced computational load and improved overall system throughput.

Hardware Acceleration (Future Consideration)​

The most effective long-term solution would involve adding dedicated hardware acceleration, such as:

  • GPU processing
  • TPU inference hardware

These accelerators are well suited for deep learning workloads and would dramatically reduce inference time.

Infrastructure Without Budget​

Challenge​

The project was developed with no infrastructure budget.

This meant:

  • no paid cloud infrastructure
  • no public domain registration
  • no managed services

All services had to be deployed on local infrastructure within the university network.

Solution​

To work within these constraints, the system was deployed entirely through self-hosted infrastructure.

Internal DNS Configuration​

Instead of public domains, services were mapped to the internal DNS system of the university network.

Custom domain rules were created to route requests internally, allowing services to be accessed through readable URLs.

Example internal endpoints included:

facelog-fe.pruebas-lab.com
facelog-be.pruebas-lab.com

Although these domains were not publicly registered, the internal DNS allowed them to function within the campus network.

Self-Hosted Infrastructure​

All services were hosted internally using containerized deployments. This approach avoided infrastructure costs while still allowing a distributed system architecture.

Database Design Decision​

Challenge​

The initial implementation used MySQL as the primary database engine.

While MySQL handled general data storage effectively, it was not ideal for vector comparison operations, which are essential for facial recognition systems.

Computing similarity between embeddings required additional processing outside the database.

Lessons Learned​

For future versions of the system, a more suitable database choice would be PostgreSQL.

PostgreSQL provides stronger support for:

  • advanced mathematical operations
  • vector extensions
  • similarity searches

Using extensions designed for vector operations would simplify embedding comparison and improve performance.

This would make it easier to compute metrics such as Euclidean distance directly inside the database layer.

Key Takeaways​

Developing FaceLog highlighted several important lessons for building machine learning systems in constrained environments:

  • Real-time computer vision systems require careful performance optimization.
  • Hardware acceleration can dramatically improve inference speed.
  • Infrastructure limitations often require creative networking and deployment solutions.
  • Choosing the right database technology is important when working with vector-based data.

Despite limited resources, the project successfully demonstrated how machine learning, distributed systems, and web technologies can be integrated into a functional real-world application.