Usaid Athar
Backend Software Engineer
PHP · Laravel · ERP Systems

The Situation

The University of Faisalabad ran their entire HR, payroll, inventory, and academic records on an Oracle Forms application built in the early 2010s. No API layer. No mobile access. Reports that took 4+ minutes during peak periods. The system was a single point of failure that the institution had outgrown. As the lead software engineer, I had to fix this.

The Constraint

We could not break payroll. Staff of 500+ depended on bi-weekly cycles running without interruption. A failed migration week meant hundreds of people did not get paid. The legacy system also had no formal data dictionary — I had to reverse-engineer the schema from Oracle Forms source files and production data patterns.

What I Built

A phased migration with a parallel-run period: new Laravel backend writing to both Oracle and MySQL simultaneously, validating parity before each module cutover. I built a MigrationValidator service that ran nightly comparisons on row counts, checksum hashes, and business-rule outputs between the two systems.

For the 4-minute payroll reports: query analysis showed 23 unindexed joins across 6 tables. Added composite indexes, rewrote N+1 queries in Eloquent, and pushed the final aggregations into a Redis-cached layer that refreshes on relevant DB events. Result: 200ms consistently.

Outcome

Zero payroll cycles missed. All modules cut over within 8 months. The system now serves 500+ concurrent users with a 99.2% uptime SLA, measured via a self-hosted Uptime Robot instance. This is the kind of software engineering that matters.

The Problem

Degree certificate fraud was rising across Pakistani institutions. Employers verifying credentials had to contact the university directly, wait days for a manual check, and had no guarantee the printed document had not been altered. The university needed a verification system that worked in the field — a smartphone scan, instant result.

The Design Decision

The QR code needed to be self-verifying — it could not rely on a database lookup alone, because database tampering was also a threat vector. I chose RSA-2048 digital signatures: the server signs a payload containing the document's key fields (student ID, degree type, issue date, institution) with a private key. The QR encodes the payload + signature. The public portal decodes it, verifies the signature, and cross-references the DB record.

Even if a QR is visually cloned, the signature will not match a tampered payload. Even if the DB record is altered, the signature will not validate against the stored original hash.

Rate Limiting & Abuse Prevention

The public portal uses a throttle:60,1 middleware per IP for verification requests, with stricter throttle:5,1 on batch endpoints. Suspicious patterns (bulk sequential ID scans) trigger a temporary block and flag the event for review.

Outcome

12,000+ documents verified since launch. Zero confirmed fraud cases in the verification system. Verification time dropped from days (manual) to under 3 seconds. The system is now being considered for rollout across the university consortium. This is what software engineering at scale looks like.

The Architecture Choice

For TecBeck's SaaS platform, I had to choose between row-level isolation (single DB, tenant column) and schema-per-tenant (separate schemas in the same MySQL instance). Row-level is simpler to implement but leaks data if you miss a query scope — and in a multi-tenant SaaS, that is catastrophic. Schema-per-tenant gives hard isolation at the database level.

The tradeoff is connection overhead. I solved this with a custom TenantConnectionMiddleware that reads the subdomain, resolves the tenant from a central registry DB, and switches the default connection via config(['database.connections.tenant.database' => $tenant->schema]). Connection switch consistently benchmarks under 50ms.

Stripe Integration

Each tenant has a Stripe Customer ID stored in the registry. Subscription events (created, updated, cancelled, payment failed) are handled via a single webhook endpoint that routes to tenant-specific handlers. Failed payment recovery uses a GracePeriodJob dispatched on invoice.payment_failed — tenants get a 7-day window before access restriction, with email reminders via queued jobs.

Real-time with Pusher + Laravel Echo

Each tenant gets their own Pusher channel namespace (tenant.{id}.*). Backend events broadcast via ShouldBroadcastNow — dashboard stats update live, in-app notifications appear instantly, and the support chat system runs over persistent WebSocket connections. Auth middleware validates channel subscriptions against the tenant context to prevent cross-tenant event leakage.