DEV Community: Ali Haider

Building a Scalable Audit & System Logging Architecture for Healthcare Applications

Ali Haider — Thu, 22 Oct 2026 14:02:30 +0000

A practical approach to separating business audit events from technical system logs for better debugging, observability, and accountability.

When people think about healthcare software, they usually think about Electronic Health Records (EHRs), appointment scheduling, billing systems, prescriptions, or patient portals.

Those features are obviously important—but after several years working on backend systems, I've learned that one of the most valuable components isn't visible to users at all.

It's logging.

Users don't notice it.

Product demos rarely mention it.

But the moment something goes wrong in production, it becomes one of the first places every engineer looks.

Questions like these suddenly become critical:

Why did this request fail?
Who updated this record?
What changed?
Was it a system issue or a user action?
When did it happen?
Can we reproduce it?

Without a well-designed logging strategy, answering those questions often means digging through databases, reproducing issues, or relying on guesswork.

With a good logging architecture, the answers are usually only a few searches away.

In this article, I'd like to share a logging architecture pattern that separates Audit Logs from System Logs, why that distinction matters, and some practical lessons I've learned while designing enterprise backend applications.

Why Logging Matters in Healthcare

Healthcare applications manage some of the most sensitive information in any industry.

Every day, systems perform operations like:

Updating patient demographics
Scheduling appointments
Recording medications
Signing clinical encounters
Updating insurance information
Managing laboratory results

Each operation changes business data that someone may need to investigate later.

Imagine receiving a production ticket that simply says:

The patient's insurance information changed yesterday.

The first question isn't **how **to fix it.

The first question is:

What actually happened?

A good logging strategy should make that easy to answer.

Audit Logs vs. System Logs

One of the biggest mistakes I see is treating audit logs and system logs as the same thing.

Although both record events, they solve completely different problems.

Audit Logs

Record business events
Who changed the data?
Business accountability
User activity
Compliance

System Logs

Record technical events
How did the application behave?
Technical troubleshooting
Request lifecycle
Performance & debugging

Think of it like this:

Audit Logs tell the story of the business.
System Logs tell the story of the application.

Keeping these responsibilities separate makes both systems much easier to maintain.

High-Level Architecture

Instead of allowing every controller or service to generate logs independently, one common approach is to centralize the logging process.

                Client

                  │

                  ▼

        HTTP Request Received

                  │

                  ▼

     Request Processing Layer

      ┌────────────┴────────────┐

      ▼                         ▼

System Logging           Business Logic

                                  │

                                  ▼

                    Audit Event Dispatcher

                                  │

               ┌──────────────────┼──────────────────┐

               ▼                  ▼                  ▼

         Domain A           Domain B           Domain C

               └──────────────────┼──────────────────┘

                                  ▼

                 Search & Analytics Platform

This separation keeps business logic focused on business problems while allowing logging to evolve independently.

System Logging

System logs describe how the application behaves.

Every incoming request typically generates a system log regardless of whether business data changes.

Typical metadata includes:

HTTP Method
Endpoint
Authenticated User
Organization ID
Client IP
Timestamp
Request ID / Correlation ID
Request Parameters
Response Status
Execution Time
Exception Details

A simplified pipeline looks like this:

Incoming Request --> Collect Request Metadata --> Execute Business Logic --> Capture Response --> Generate System Log --> Search Platform

Capturing request metadata before executing business logic is especially valuable.

Even if an exception occurs later, engineers still have enough context to investigate what happened.

Audit Logging

Audit logging has a different purpose.

Not every request deserves an audit event.

Viewing a dashboard usually doesn't.

Updating a patient record probably does.

Instead of placing audit logic throughout the application, a centralized dispatcher can determine whether an action should generate an audit event.

A simplified flow looks like this.

Business Operation --> Audit Dispatcher --> Determine Business Domain --> Module A/B/C --> Compare Previous State --> Generate Audit Event --> Store Event

Each module owns only the logic related to its own domain.

For example:

Create Record
Update Record
Delete Record
Restore Record

This keeps the architecture modular and avoids duplicating logging logic across multiple controllers or services.

Choosing a Search Platform

As applications grow, log volume increases rapidly.

Searching millions of log entries using relational databases alone can become inefficient.

Search and analytics platforms such as Elasticsearch, OpenSearch, or similar technologies are designed specifically for this workload.

Benefits include:

Full-text search
Fast filtering
Near real-time indexing
Time-based queries
Aggregations
Dashboards
Scalable storage

Instead of storing logs alongside transactional data, indexing them separately makes production investigations significantly faster.

Benefits of Separating Audit & System Logs

After adopting this architecture, organizations often notice several practical improvements.

Faster Debugging

Engineers spend less time reproducing issues because request history is already available.

Better Accountability

Business actions become traceable.

Teams can understand who performed an action, what changed, and when it happened.

Easier Production Support

Support teams can investigate incidents without involving developers in every case.

Improved Observability

System logs provide visibility into:

API failures
Background jobs
Integration issues
Slow requests
Exceptions

Cleaner Architecture

Business logic remains focused on business functionality instead of logging implementation.

Performance Considerations

Logging should improve observability—not reduce application performance.

Some practices that have worked well include:

Log meaningful business events.

Avoid storing sensitive information.

Keep payloads concise.

Index commonly searched fields.

Rotate or archive old logs.

Consider asynchronous logging for high-volume systems.

Good logging should be informative without becoming expensive.

Common Logging Mistakes

Some mistakes appear repeatedly across enterprise applications.

❌ Mixing audit logs with system logs.

❌ Logging passwords or authentication tokens.

❌ Logging every single request without a purpose.

❌ Making logs impossible to search.

❌ Ignoring retention and archival strategies.

A thoughtful logging strategy is just as important as the logging technology itself.

Lessons Learned

One lesson has stayed with me throughout multiple backend projects:

Logging should never be treated as something you add after a feature is finished.

It should be part of the system architecture from the beginning.

Good logging doesn't only help developers.

It helps support engineers.

It helps administrators.

It helps operations teams.

And ultimately, it improves confidence in the software itself.

Looking ahead, I also think AI will change how we interact with logs.

Instead of manually searching thousands of entries, AI systems will be able to summarize incidents, identify unusual behavior, explain failures in natural language, and assist engineers during production investigations.

For healthcare systems, where reliability and accountability are essential, that evolution is particularly exciting.

Final Thoughts

Logging isn't the feature users ask for.

It's the feature engineers appreciate when everything else goes wrong.

Separating Audit Logs from System Logs creates a cleaner architecture, simplifies troubleshooting, and improves long-term maintainability.

Whether you're building healthcare software, SaaS products, or enterprise platforms, investing in a thoughtful logging strategy will pay dividends long after the feature has shipped.

Because in production systems, understanding what happened is often just as important as making sure it never happens again.

Discussion

How do you approach logging in your applications?

Do you separate audit logs from system logs?
Have you adopted centralized logging?
Which search platform are you using—Elasticsearch, OpenSearch, Loki, Splunk, or something else?

I'd love to hear how other teams are solving these challenges.

🚨 PHP developers: Check your production PHP version. A critical security update is out.

Ali Haider — Thu, 22 Oct 2026 13:09:09 +0000

On October 21, the PHP team released security updates for PHP 8.5, 8.4, 8.3 and 8.2.

The patched versions are:

🔹 PHP 8.5.12

🔹 PHP 8.4.27

🔹 PHP 8.3.36

🔹 PHP 8.2.35

These releases address two critical vulnerabilities:

• CVE-2026-109618 — related to out-of-memory handling

• CVE-2026-109619 — related to stale internal state

Both can potentially lead to remote code execution without authentication. That means the issue isn't limited to application-level bugs.

Here's what I'd check as a backend engineer:

✅ Identify the PHP versions running across production servers, containers and CI/CD environments.

✅ Check whether your hosting provider or Linux distribution has supplied patched packages.

✅ Update to a fixed version and restart PHP workers or services where required.

✅ Verify the running version after deployment.

✅ Review your upgrade plan if you're still using an unsupported PHP branch.

One more important detail: PHP 8.2 reaches end of life on December 31, 2026, so teams using it should also plan their next upgrade.

Modern frameworks, clean architecture and automated tests are important—but keeping the underlying runtime secure is equally important.

When was the last time you checked the PHP version running in your production environment?

Official advisory: https://www.php.net/archive/2026.php#2026-10-21-5

Stop Optimizing the Wrong Things: Practical Database Optimization Techniques Every Backend Developer Should Know

Ali Haider — Mon, 03 Aug 2026 19:30:08 +0000

We've all been there.

An API that used to respond in milliseconds suddenly becomes slower as the database grows. The application logic hasn't changed much, but performance keeps degrading.

In many cases, the problem isn't the framework or the programming language—it's how we're interacting with the database.

This article shares a few practical optimization techniques I've used while working on backend systems. These aren't advanced tricks; they're small improvements that can make a noticeable difference in production environments.

1. Don't Apply Functions to Indexed Columns

Imagine you have an indexed column named updated.

A common approach is filtering records like this:

WHERE DATE(updated) = '2026-07-30'

Although it works, there's a hidden cost.

Because updated is wrapped inside a function, the database usually can't use the index efficiently. Instead of performing an index range scan, it may need to evaluate every row.

A better approach is to compare the raw timestamp:

WHERE updated >= '2026-07-30 00:00:00'
AND updated < '2026-07-31 00:00:00'

This allows the database optimizer to use the index effectively.

2. Convert Input Instead of Every Database Row

I recently reviewed code that converted every timestamp inside SQL using time zone functions.

While technically correct, it forced the database to perform a conversion for every matching row.

Instead, convert the user's input once in your application:

$fromLocal->setTimezone(new DateTimeZone('UTC'));

Then execute a simple query:

WHERE updated >= ?
AND updated < ?

The result is easier to read, more maintainable, and usually much faster.

3. Don't Load Thousands of Rows Just to Count Them

I've seen code similar to this:

$total = count($Model->query($sql));

It works, but think about what's happening.

The database sends every matching row to your application.

Your application allocates memory for every record.

Finally, PHP counts the array.

If the query returns 200,000 rows, you've transferred and stored 200,000 records simply to obtain a number.

Instead, let the database do the counting:

SELECT COUNT(*)
FROM ...

Or, if you're wrapping an existing query:

SELECT COUNT(*)
FROM (
    ...
) results;

The database returns a single integer instead of thousands of records.

4. Write Queries That Scale

A query that performs well with 500 rows may become a bottleneck when your database reaches millions of records.

Whenever you review a query, ask yourself:

Can this use an index?
Am I processing unnecessary data?
Can the database perform this operation more efficiently than my application?
Am I transferring more data than I actually need?

These questions often reveal opportunities for optimization.

5. Readability Is Also an Optimization

Performance isn't the only goal.

Code that is easy to understand is easier to maintain, debug, and improve.

For example, converting user input once in the application layer is often simpler than embedding multiple conditional time zone conversions inside SQL.

Future developers—including your future self—will thank you.

Final Thoughts

Database optimization doesn't always require rewriting your architecture.

Often, the biggest gains come from small improvements:

Avoid wrapping indexed columns in functions.
Convert user input instead of every database row.
Use COUNT(*) when you only need totals.
Return only the data you actually need.
Think about how the database executes your query—not just whether the query works.

As your application grows, these habits become increasingly valuable. Small optimizations applied to frequently executed queries can have a meaningful impact on performance, resource usage, and overall scalability.

What optimization technique has had the biggest impact on your applications? I'd love to hear your experiences in the comments.

Flexible Boolean Validation for Laravel APIs — Handling “true”/“false” Strings Without the Headache

Ali Haider — Mon, 30 Mar 2026 20:52:18 +0000

Every Laravel developer has hit this at some point.

You’re working on a clean API. Everything looks good. Then suddenly validation fails because the frontend sent "true" instead of true.

Laravel’s default boolean rule is excellent for strictness, but it rejects common string values like "true" and "false" that come from JavaScript, React/Vue forms, query strings, or external services.

The result? Scattered filter_var() calls, custom rules, or manual casting — repeated across every project.

I got tired of the same workaround and decided to fix it once and for all.

Introducing flexible-boolean

I built a small, focused package that extends Laravel’s boolean validation to support real-world API inputs while keeping everything clean and secure.

Supported values now include:

"true" / "false" (strings)
1 / 0
Native true / false

It integrates seamlessly with Laravel’s validation system — no side effects, no performance hit.

Quick Example

Install via Composer:

composer require alihaider/flexible-boolean

Then use it in your Form Requests:

public function rules(): array
{
    return [
        'is_active'     => ['required', 'boolean:flexible'],
        'newsletter'    => new FlexibleBooleanRule(),
        'is_published'  => 'boolean', // still works as before
    ];
}

You can also register the rule globally if you prefer.

Before vs After

Before: Random 422 errors + extra controller logic
After: Predictable validation that just works with frontend data
It’s a tiny package, but it saves a surprising amount of debugging time when building production APIs.

Let’s Discuss

How are you handling boolean values from the frontend in your Laravel projects today?

Manual casting?
Custom rules per project?
Something else entirely?

Drop your preferred approach in the comments — I’m curious to see the different solutions the community uses.

Package

https://packagist.org/packages/alihaider/flexible-boolean

If you found this useful, give it a like or save it for later. Happy coding!