Forem: Mohamed Azmy

Publish Subscribe Model

Mohamed Azmy — Sun, 22 Feb 2026 16:35:02 +0000

A notification system is responsible for sending alerts to users, such as breaking news, product updates, event reminders, and promotions. Notifications are not limited to mobile push messages. In practice, there are three major notification channels: push notifications, SMS messages, and emails.

Defining the Scope and Requirements

Before designing a notification system, we must first understand the problem and clarify the system requirements. System design problems are often open-ended, so asking the right questions is essential.

Key requirements include:

What types of notifications are supported?
Is the system real-time?
Which devices should receive notifications?
What triggers notifications?
Can users opt out?
What is the expected scale?

In our design, the system supports push notifications, SMS, and email. Notifications should be delivered as quickly as possible, with small delays acceptable under heavy load.

The system must work across iOS devices, Android devices, and desktop or laptop computers.

Notifications can be triggered by user actions through client applications, or by server-side scheduled jobs such as reminders and marketing campaigns.

Users must also be able to opt out, and the system must respect their notification preferences.

At scale, the system sends around 10 million push notifications, 1 million SMS messages, and 5 million emails every day.

This makes it a large-scale system that must be fast, reliable, scalable, and support multiple delivery channels.

High-Level Notification System Architecture

At a high level, services in our system do not communicate directly with external providers like Apple or Google. Instead, they send requests to a centralized Notification Service API.

This notification service determines the type of message — push, SMS, or email — builds the correct payload, and routes it through the appropriate delivery channel.

Finally, third-party providers handle the actual delivery to user devices.

Notification Delivery Channels

A modern notification system must support multiple channels, each with its own external provider.

iOS Push Notifications (APNs)

For iOS push notifications, the flow includes three components:

Provider: our server that builds the notification request
APNs: Apple Push Notification Service that delivers the message
iOS Device: the client that receives and displays the alert

The provider requires:

A device token (unique identifier for the iPhone)
A payload (JSON containing the title, body, and metadata)

Android Push Notifications (FCM)

Android push notifications follow a similar flow, except that Firebase Cloud Messaging (FCM) is used instead of APNs.

SMS Notifications

SMS messages are typically delivered through third-party providers such as Twilio or Nexmo, rather than being sent directly from internal servers.

Email Notifications

Most companies rely on third-party email services like SendGrid or Mailchimp due to their high delivery rates, reliability, and analytics support.

Collecting User Contact Information

To send notifications, the system must store the user’s contact details. When a user signs up or installs the application, our API servers collect this information and store it in the database.

Typical stored data includes:

Device tokens for push notifications
Phone numbers for SMS
Email addresses for email delivery

A simple database structure includes:

User Table: profile information, email, phone number
Device Table: device tokens linked to the user (supporting multiple devices per user)

Core System Components

The key building blocks of the notification architecture include:

Services that trigger notifications (microservices, cron jobs, distributed systems)
A central Notification System that receives requests and builds payloads
Third-party providers responsible for delivering notifications
User devices that ultimately receive the alerts

Third-Party Provider Considerations

Integrating external providers introduces two important requirements:

Extensibility: adding or replacing providers should require minimal changes
Provider Availability: some providers may not work in certain regions (e.g., FCM in China), requiring alternatives like JPush

Problems with the Initial Single-Server Design

A simple architecture with only one notification server leads to three major challenges:

Single Point of Failure: if the server fails, all notifications stop
Hard to Scale: individual components cannot scale independently
Performance Bottlenecks: slow tasks and API delays can overwhelm the system

Improving Scalability and Reliability

To evolve the design into a production-ready system, we introduce three key improvements:

Separate the database and cache into independent services for better scalability
Add multiple notification servers behind a load balancer for horizontal scaling
Introduce message queues to decouple components and enable asynchronous processing

With message queues, services simply enqueue notification jobs, and worker servers process them asynchronously. This removes bottlenecks, improves resilience, and supports high traffic efficiently.

Conclusion

By combining multiple delivery channels, scalable infrastructure, and asynchronous message queues, we can build a modern notification system that is reliable, extensible, and capable of handling millions of notifications per day.

Notification System Design

Mohamed Azmy — Sat, 07 Feb 2026 17:25:17 +0000

A notification system is responsible for sending alerts to users, such as breaking news, product updates, event reminders, and promotions.

Notifications are not limited to mobile push messages. In practice, there are three major notification channels: push notifications, SMS messages, and emails.

Defining the Scope and Requirements

Key requirements include:

• What types of notifications are supported?
• Is the system real-time?
• Which devices should receive notifications?
• What triggers notifications?
• Can users opt out?
• What is the expected scale?

In our design, the system supports push notifications, SMS, and email. Notifications should be delivered as quickly as possible, with small delays acceptable under heavy load.

The system must work across iOS devices, Android devices, and desktop or laptop computers.

Notifications can be triggered by user actions through client applications, or by server-side scheduled jobs such as reminders and marketing campaigns.

Users must also be able to opt out, and the system must respect their notification preferences.

At scale, the system sends around 10 million push notifications, 1 million SMS messages, and 5 million emails every day.

This makes it a large-scale system that must be fast, reliable, scalable, and support multiple delivery channels.

High-Level Notification System Architecture

At a high level, services in our system do not communicate directly with external providers like Apple or Google. Instead, they send requests to a centralized Notification Service API.

This notification service determines the type of message — push, SMS, or email — builds the correct payload, and routes it through the appropriate delivery channel.

Finally, third-party providers handle the actual delivery to user devices.

Notification Delivery Channels

A modern notification system must support multiple channels, each with its own external provider.

iOS Push Notifications (APNs)

For iOS push notifications, the flow includes three components:

• Provider: our server that builds the notification request
• APNs: Apple Push Notification Service that delivers the message
• iOS Device: the client that receives and displays the alert

The provider requires:

• A device token (unique identifier for the iPhone)
• A payload (JSON containing the title, body, and metadata)

Android Push Notifications (FCM)

Android push notifications follow a similar flow, except that Firebase Cloud Messaging (FCM) is used instead of APNs.

SMS Notifications

SMS messages are typically delivered through third-party providers such as Twilio or Nexmo, rather than being sent directly from internal servers.

Email Notifications

Most companies rely on third-party email services like SendGrid or Mailchimp due to their high delivery rates, reliability, and analytics support.

Collecting User Contact Information

To send notifications, the system must store the user’s contact details. When a user signs up or installs the application, our API servers collect this information and store it in the database.

Typical stored data includes:

• Device tokens for push notifications
• Phone numbers for SMS
• Email addresses for email delivery

A simple database structure includes:

• User Table: profile information, email, phone number
• Device Table: device tokens linked to the user (supporting multiple devices per user)

Core System Components

The key building blocks of the notification architecture include:

• Services that trigger notifications (microservices, cron jobs, distributed systems)
• A central Notification System that receives requests and builds payloads
• Third-party providers responsible for delivering notifications
• User devices that ultimately receive the alerts

Third-Party Provider Considerations

Integrating external providers introduces two important requirements:

• Extensibility: adding or replacing providers should require minimal changes
• Provider Availability: some providers may not work in certain regions (e.g., FCM in China), requiring alternatives like JPush

Problems with the Initial Single-Server Design

A simple architecture with only one notification server leads to three major challenges:

• Single Point of Failure: if the server fails, all notifications stop
• Hard to Scale: individual components cannot scale independently
• Performance Bottlenecks: slow tasks and API delays can overwhelm the system

Improving Scalability and Reliability

To evolve the design into a production-ready system, we introduce three key improvements:

• Separate the database and cache into independent services for better scalability
• Add multiple notification servers behind a load balancer for horizontal scaling
• Introduce message queues to decouple components and enable asynchronous processing

With message queues, services simply enqueue notification jobs, and worker servers process them asynchronously. This removes bottlenecks, improves resilience, and supports high traffic efficiently.

Conclusion

HTTP Push Mechanism

Mohamed Azmy — Sat, 31 Jan 2026 09:49:49 +0000

Modern web applications increasingly rely on real-time communication. Whether it's live notifications, collaborative tools, or multiplayer games, waiting for the client to ask for updates is often not good enough. This is where HTTP Push and persistent connections come into play.

In this article, we’ll explore:

• How traditional HTTP Pull works
• The role of Time To Live (TTL)
• Persistent connections and heartbeat mechanisms
• Why HTTP Push can be resource-intensive
• Common technologies used to implement it

The Traditional HTTP Pull Model

By default, web communication follows the HTTP Pull model:

• The client sends a request
• The server processes it
• The server returns a response
• The connection is closed

Each request has a Time To Live (TTL), typically between 30 and 60 seconds, depending on the browser and environment.

If the server does not respond within this time window, the browser assumes the request has stalled and closes the connection. The client must then send a new request to try again.

This behavior is intentional. Open connections consume server resources such as memory and file descriptors, and servers can only handle a limited number of simultaneous connections. Without a timeout mechanism, a server could eventually exhaust its resources.

When HTTP Pull Is Not Enough

The HTTP Pull model works well for most use cases, but it breaks down in scenarios where:

• The server response takes longer than the TTL
• The server needs to send data as soon as it becomes available
• Low-latency, real-time updates are required

In these cases, repeatedly polling the server is inefficient and introduces unnecessary delays.

Persistent Connections and HTTP Push

To solve this, we use persistent connections.

A persistent connection remains open between the client and the server instead of closing after a single request-response cycle. Once established, the server can push data to the client whenever it is ready, without waiting for a new request.

This communication pattern is commonly referred to as HTTP Push and forms the foundation of many real-time web systems.

Keeping the Connection Alive: Heartbeat Interceptors

Browsers are designed to close idle connections. To prevent this from happening, persistent connections rely on heartbeat mechanisms.

Heartbeats are small, lightweight messages exchanged periodically between the client and the server. They usually contain no meaningful data. Their sole purpose is to signal that the connection is still active and should not be terminated due to inactivity.

Without heartbeats, browsers or proxies would close long-lived connections, making HTTP Push unreliable.

The Cost of Persistent Connections

While powerful, persistent connections come with trade-offs.

Compared to traditional HTTP Pull:

• They consume more memory per client
• They require more careful connection management
• They increase server complexity

Because each client holds an open connection, scalability becomes a critical concern. This is why HTTP Push should be used only when real-time communication is truly required.

Real-World Use Case: Multiplayer Browser Games

A clear example where HTTP Push is essential is browser-based multiplayer games.

Players need to receive continuous, real-time updates about game state, actions, and events. Polling the server every few seconds would result in poor responsiveness and a degraded user experience.

In this scenario, maintaining a persistent connection dramatically improves performance and responsiveness.

Common Technologies for HTTP Push

Several technologies are commonly used to implement long-lived connections:

• Ajax Long Polling – Simulates push by keeping requests open until data is available
• WebSockets – Provides full-duplex, real-time communication over a single persistent connection
• Server-Sent Events (SSE) – Allows servers to push one-way updates to clients over HTTP

Each approach has its own strengths and trade-offs, and the right choice depends on the application’s requirements.

Conclusion

HTTP Push enables real-time communication by keeping connections open and allowing servers to send data as soon as it’s available. While this approach is more resource-intensive than traditional HTTP Pull, it is indispensable for modern applications that demand low latency and real-time updates.

Understanding how TTL, persistent connections, and heartbeat mechanisms work together helps engineers design systems that are both responsive and scalable.

When used thoughtfully, HTTP Push can significantly enhance the user experience in modern web applications.

Linux: The Secret Weapon for Developers

Mohamed Azmy — Tue, 06 Jan 2026 17:54:03 +0000

Linux is an operating system like Windows and macOS, but for a long time it was mostly associated with servers and enterprise environments. Early Linux distributions were powerful but not very user-friendly, mainly because of complex interfaces and setup processes. Over the years, developers around the world have continuously improved Linux, making it easier to use, more polished, and more accessible.

Today, Linux is everywhere. It runs on personal laptops, home desktops, cloud platforms, enterprise servers, cars, smart devices, and critical infrastructure. This widespread adoption is not accidental — Linux offers several advantages that make it especially attractive to programmers and developers.

Quick Overview

The short video below highlights why many developers consider Linux their secret weapon. It gives a fast visual breakdown of the key reasons programmers prefer Linux for development work.

Why Programmers Choose Linux

One of the biggest reasons programmers choose Linux is security. Linux is built around a strong permission model that separates regular users from administrative access. Most system-level changes require root privileges, which makes it much harder for viruses and malware to cause serious damage. This design also improves privacy, since Linux does not constantly collect or upload user data in the background.

Customization is another major advantage. Linux allows developers to fully control how their system looks and behaves. Users can choose from different desktop environments, customize themes, icons, fonts, and system tools, and create workflows that perfectly match their needs. Shell scripting makes it easy to automate tasks and improve productivity.

Linux is also extremely efficient with hardware resources. Unlike many modern operating systems that slow down older machines, Linux can run smoothly on low-end or outdated hardware. It uses CPU and memory efficiently, making it an excellent choice for development machines, servers, and embedded systems.

Automation plays a huge role in Linux-based workflows. Developers can write bash scripts to automate repetitive tasks such as file management, backups, data processing, deployments, and system maintenance. This saves time, reduces errors, and allows programmers to focus on building software instead of managing systems.

Another strong point is the Linux community. Millions of developers around the world actively contribute to forums, documentation, and open-source projects. If you encounter a problem, chances are someone else has already faced it and shared a solution. For enterprises, professional support is also available from companies like Red Hat and Canonical.

Linux is known for its stability and reliability. Many Linux systems run for months or even years without needing a reboot. This is why most servers, cloud platforms, and data centers rely on Linux. Updates usually do not interrupt running services, which helps reduce downtime and operational costs.

Finally, Linux is open source. Anyone can view, modify, and improve the source code without paying license fees. This freedom allows developers, companies, and even entire countries to build custom Linux systems that fit their needs while keeping costs low and control high.

Conclusion

Linux has evolved from a server-only operating system into a powerful, flexible, and reliable platform for developers. With strong security, deep customization, efficient performance, automation capabilities, community support, and open-source freedom, Linux continues to be a secret weapon for programmers around the world.

Understanding Coupling: Afferent vs Efferent Dependencies in System Design

Mohamed Azmy — Mon, 05 Jan 2026 07:34:15 +0000

There are two important definitions when measuring coupling between parts of a codebase:

Afferent Coupling (Ca) Measures how many other components depend on a given component.
Efferent Coupling (Ce) Measures how many components a given component depends on.

Both metrics become critical when you’re planning to change the structure of a system.

Why Coupling Matters During Refactoring

Imagine you have a monolithic application and you decide to migrate it to microservices.

You’ll quickly notice shared classes such as Address, Money, or UserProfile.

In a monolith, reusing a class like Address across multiple modules is completely normal. But once you start decomposing the system, you must ask important questions:

How many parts of the system depend on Address?
If it changes or gets extracted, what will break?
Which modules will be affected directly or indirectly?

This is exactly where coupling metrics become valuable.

Afferent Coupling (Ca)

Afferent coupling tells you:

“How many components rely on this one?”

High afferent coupling usually means:

The component is widely used
Any change is risky
It must be stable and carefully designed

Components with high Ca are often core domain concepts.

Efferent Coupling (Ce)

Efferent coupling answers a different question:

“How many components does this one depend on?”

High efferent coupling often indicates:

Many external dependencies
Higher fragility
Poor separation of concerns

Making Safer Architectural Decisions

Measuring coupling helps you:

Understand the impact of changes before making them
Reduce surprises during refactoring
Make architectural decisions based on data, not intuition

Visualizing Dependencies

Most modern platforms provide tools that analyze dependencies between code components.

These tools usually visualize relationships between:

Classes
Packages
Layers or modules

Often presented as a dependency matrix that clearly shows who depends on whom.

Tooling Examples

Java Ecosystem

JDepend is a popular Java tool that analyzes coupling at the package level and provides clear metrics. This allows architectural decisions to be made based on numbers, not gut feelings.

PHP Ecosystem

In PHP, one of the most popular tools for dependency analysis is Deptrac.

Deptrac is designed to:

Analyze dependencies between layers or modules
Enforce architectural boundaries
Reveal hidden coupling in large PHP projects

It is especially useful for:

Laravel applications
Modular monoliths
Microservice migration preparation

Final Thoughts

Coupling analysis is not theoretical — it’s a practical tool.

If you work on large systems, maintain legacy code, plan to split a monolith, or want to improve architecture incrementally, understanding afferent and efferent coupling will help you make safer decisions.

Good architecture starts with visibility, and coupling metrics give you exactly that.

Understanding Coupling: Afferent vs Efferent Dependencies in System Design

Mohamed Azmy — Mon, 05 Jan 2026 07:34:15 +0000

There are two important definitions when measuring coupling between parts of a codebase:

Afferent Coupling (Ca) Measures how many other components depend on a given component.
Efferent Coupling (Ce) Measures how many components a given component depends on.

Both metrics become critical when you’re planning to change the structure of a system.

Why Coupling Matters During Refactoring

Imagine you have a monolithic application and you decide to migrate it to microservices.

You’ll quickly notice shared classes such as Address, Money, or UserProfile.

In a monolith, reusing a class like Address across multiple modules is completely normal. But once you start decomposing the system, you must ask important questions:

How many parts of the system depend on Address?
If it changes or gets extracted, what will break?
Which modules will be affected directly or indirectly?

This is exactly where coupling metrics become valuable.

Afferent Coupling (Ca)

Afferent coupling tells you:

“How many components rely on this one?”

High afferent coupling usually means:

The component is widely used
Any change is risky
It must be stable and carefully designed

Components with high Ca are often core domain concepts.

Efferent Coupling (Ce)

Efferent coupling answers a different question:

“How many components does this one depend on?”

High efferent coupling often indicates:

Many external dependencies
Higher fragility
Poor separation of concerns

Making Safer Architectural Decisions

Measuring coupling helps you:

Understand the impact of changes before making them
Reduce surprises during refactoring
Make architectural decisions based on data, not intuition

Visualizing Dependencies

Most modern platforms provide tools that analyze dependencies between code components.

These tools usually visualize relationships between:

Classes
Packages
Layers or modules

Often presented as a dependency matrix that clearly shows who depends on whom.

Tooling Examples

Java Ecosystem

JDepend is a popular Java tool that analyzes coupling at the package level and provides clear metrics. This allows architectural decisions to be made based on numbers, not gut feelings.

PHP Ecosystem

In PHP, one of the most popular tools for dependency analysis is Deptrac.

Deptrac is designed to:

Analyze dependencies between layers or modules
Enforce architectural boundaries
Reveal hidden coupling in large PHP projects

It is especially useful for:

Laravel applications
Modular monoliths
Microservice migration preparation

Final Thoughts

Coupling analysis is not theoretical — it’s a practical tool.

Good architecture starts with visibility, and coupling metrics give you exactly that.

Shared Library vs Shared Service: A Better Alternative for Code Reuse

Mohamed Azmy — Mon, 05 Jan 2026 07:26:39 +0000

The primary alternative to using a Shared Library is using a Shared Service.

Instead of reusing code through a shared library inside a Laravel project, you can move shared logic into an independent service, and let other services or modules consume it via an API or client.

This approach shifts reuse from code-level sharing to behavior-level sharing.

A Practical Example

Imagine you have multiple services that deal with customers, such as:

Orders Service
Notifications Service

All of them need to check the customer’s balance before performing certain operations.

The Shared Library Approach

You could:

Create a shared library
Import it into every service
Re-deploy all services whenever the logic changes

This creates tight coupling and coordinated deployments.

The Shared Service Approach

Instead, you create a dedicated CustomerBalanceService.

Each service:

Calls CustomerBalanceService when it needs to validate customer balance
Does not own the balance calculation logic

Now, if you:

Change the calculation rules
Add new validation constraints

Only CustomerBalanceService needs to be modified and deployed. All consuming services automatically benefit from the change.

Composition Over Inheritance

The key idea here is that reuse happens through composition, not inheritance.

Services use CustomerBalanceService
They do not extend or inherit from its classes

This provides:

Greater flexibility
Better service autonomy
Looser coupling between components

Each service remains independent, with a clear contract between them.

Architectural Trade-offs

Like any architectural decision, shared services come with trade-offs.

1. Change Risk

Any change in the shared service can impact all dependent services. This requires:

Strong versioning
Backward compatibility
Careful contract design

2. Performance

Calling a shared service usually means:

A network call
Higher latency compared to a local library call

This must be evaluated carefully, especially in high-throughput paths.

3. Fault Tolerance

If the shared service goes down:

All dependent services may be affected

This makes the following essential parts of the design:

Circuit breakers
Retries
Caching
Fallback strategies

Final Thought

Shared services promote:

Better separation of concerns
Centralized business rules
Independent deployments

But they also introduce:

Runtime dependencies
Operational complexity

Choose shared services when business logic truly belongs to a single authority, and be intentional about the trade-offs.

Good architecture isn’t about eliminating problems — it’s about choosing which problems you’re willing to manage.

Shared Library vs Shared Service: A Better Alternative for Code Reuse

Mohamed Azmy — Mon, 05 Jan 2026 07:26:39 +0000

The primary alternative to using a Shared Library is using a Shared Service.

This approach shifts reuse from code-level sharing to behavior-level sharing.

A Practical Example

Imagine you have multiple services that deal with customers, such as:

Orders Service
Notifications Service

All of them need to check the customer’s balance before performing certain operations.

The Shared Library Approach

You could:

Create a shared library
Import it into every service
Re-deploy all services whenever the logic changes

This creates tight coupling and coordinated deployments.

The Shared Service Approach

Instead, you create a dedicated CustomerBalanceService.

Each service:

Calls CustomerBalanceService when it needs to validate customer balance
Does not own the balance calculation logic

Now, if you:

Change the calculation rules
Add new validation constraints

Only CustomerBalanceService needs to be modified and deployed. All consuming services automatically benefit from the change.

Composition Over Inheritance

The key idea here is that reuse happens through composition, not inheritance.

Services use CustomerBalanceService
They do not extend or inherit from its classes

This provides:

Greater flexibility
Better service autonomy
Looser coupling between components

Each service remains independent, with a clear contract between them.

Architectural Trade-offs

Like any architectural decision, shared services come with trade-offs.

1. Change Risk

Any change in the shared service can impact all dependent services. This requires:

Strong versioning
Backward compatibility
Careful contract design

2. Performance

Calling a shared service usually means:

A network call
Higher latency compared to a local library call

This must be evaluated carefully, especially in high-throughput paths.

3. Fault Tolerance

If the shared service goes down:

All dependent services may be affected

This makes the following essential parts of the design:

Circuit breakers
Retries
Caching
Fallback strategies

Final Thought

Shared services promote:

Better separation of concerns
Centralized business rules
Independent deployments

But they also introduce:

Runtime dependencies
Operational complexity

Choose shared services when business logic truly belongs to a single authority, and be intentional about the trade-offs.

Good architecture isn’t about eliminating problems — it’s about choosing which problems you’re willing to manage.

Microservices Are Not Always the Right Answer

Mohamed Azmy — Tue, 30 Dec 2025 12:59:41 +0000

It’s not always correct to split a system into microservices.
Just like there are valid reasons to break a service apart, there are also strong reasons to keep services together — or not split them at all in the first place.

These reasons are known as Granularity Integrators.
They are the factors that make you pause before decomposing a service, or justify keeping it large.

The real skill in choosing the right service size is balancing decomposition drivers with integration drivers, not blindly following one direction.

Below are the four most important reasons to integrate services or avoid splitting them.

1. Database Transactions (ACID)

If an operation requires a strong ACID transaction across multiple parts of the system, those parts usually should not be separate services.

Example (Laravel)

Creating an Order and updating Stock must happen together.
If one fails, both must roll back.

If these operations live in separate services, you’ll need:

Distributed transactions
Complex compensation logic
Higher failure scenarios

In this case, integration or a monolith is a logical and simpler choice.

2. Workflow & Choreography Complexity

Ask yourself:

Do services need to communicate heavily to complete a single business operation?

Example:-

Order Service
Payment Service
Shipping Service

If every order requires constant back-and-forth communication between these services, splitting them may:

Increase latency
Increase operational complexity
Make debugging much harder

High communication overhead is often a sign that separation may hurt more than help.

3. Shared Code

Do multiple services depend on the same complex logic?

Example (Laravel)

Imagine having complex validation logic reused across several services.

If you end up:

Copying the same code everywhere
Or creating shared services with frequent calls

Then service separation becomes noisy and fragile.
In such cases, keeping the logic together can be cleaner and more maintainable.

4. Database Relationships

Even if you can split the code — can you split the data?

Example

Entities like:

Users
Orders
Payments

Often have strong relational dependencies.

If services require:

Frequent joins
Strong consistency guarantees
Tight coupling at the data level

Then splitting them introduces:

Complex synchronization
Consistency issues
Endless edge cases

Sometimes, the database model itself argues against microservices.

Final Thoughts

Microservices are not a goal — they are an architectural choice.

Over-splitting increases complexity
Over-integrating reduces flexibility

Good architecture is about balance.
You split or integrate based on real constraints and domain needs, not trends or hype.

Design for reality — not fashion.

Extensibility: A Strong Reason to Split a Large Service

Mohamed Azmy — Tue, 30 Dec 2025 07:34:00 +0000

One of the most important reasons to break down a large service into smaller ones is extensibility — the ability to add new functionality easily as the service context grows.

A Practical Example: Payment Service

Imagine you have a Payment Service responsible for handling payments and refunds using multiple payment methods, such as:

Credit Cards.
Gift Cards.
PayPal.

Now the business decides to support additional payment methods:

Store Credit from returns.
Reward Points.
Apple Pay or Samsung Pay.

The Problem with One Large Service

If all of this logic lives inside one large service, every time you add a new payment method, you are forced to:

Re-test all existing payment methods, not just the new one.
Re-deploy the entire service, including unchanged functionality.
Deal with larger test suites and higher risk of regression.

This increases development time, raises risk, and makes it harder to introduce new payment methods quickly.

Splitting by Responsibility

Now imagine splitting that large service into smaller, focused services:

Credit Card Processing Service.
Gift Card Processing Service.
PayPal Processing Service.

With this approach, adding a new payment method like Reward Points means:

Developing only one new service.
Testing only that service.
Deploying it independently.

The Result

Faster development.
Smaller and more focused test scopes.
Lower risk during deployment.

When Extensibility Is a Valid Reason

Use extensibility as a reason to split services only if:

You are confident that new functionality will be added frequently in the future.
Or the domain naturally evolves over time.

Examples

Notification Service:
It’s relatively rare to add new notification channels (SMS, Email, Letters), so keeping it as a single service often makes sense.
Payment Processing:
New payment methods are very likely to be introduced, so splitting services by payment type is a practical and scalable design choice.

Final Thought
Extensibility is not about splitting services prematurely — it’s about anticipating growth where growth is expected.

Design your services based on how the domain evolves, not just on how it looks today.

Auditing Sensitive Data Changes in Laravel: Securing High-Risk Operations

Mohamed Azmy — Sun, 31 Aug 2025 06:53:37 +0000

When working with sensitive data—such as financial records, user roles, or confidential information—tracking changes is not optional, it’s mandatory.

Unlike general model updates, sensitive data changes must be audited separately to ensure that:

You know exactly who changed the data.
You can see what the data was before and after.
You maintain compliance with regulations (GDPR, HIPAA, PCI DSS, etc.).

In Laravel, this can be achieved by combining Events, Middleware, and Custom Audit Logs.

Why Sensitive Data Auditing is Different

Not all model changes are equal. Updating a blog title is harmless, but changing a user’s balance, password, or permissions is critical.
Sensitive changes need extra auditing logic: e.g., store the user’s IP, device, or even require double approval.

Example: Auditing Balance Changes in Laravel

01) Install the Package

composer require owen-it/laravel-auditing

02) Publish Config File

php artisan vendor:publish --provider "OwenIt\Auditing\AuditingServiceProvider"

This will create a configuration file at config/audit.php.
03) Run Migration

php artisan migrate

04) Enable Auditing on a Model

use OwenIt\Auditing\Contracts\Auditable;

class Post extends Model implements Auditable
{
    use \OwenIt\Auditing\Auditable;

    protected $fillable = ['title', 'content'];
}

By adding the Auditable trait, Laravel will now automatically log every change to this model.

05) Test It Out

$post = Post::find(1);
$post->update(['title' => 'New Title']);

06) Check the Audit Table
A new record will be created in the audits table:

{
  "user_id": 2,
  "event": "updated",
  "auditable_type": "App\\Models\\Post",
  "auditable_id": 1,
  "old_values": { "title": "Old Title" },
  "new_values": { "title": "New Title" },
  "created_at": "2025-08-31 10:15:00"
}

Here you can clearly see:

Which user made the change (user_id).
What was changed (old_values → new_values).
When the change happened (created_at).

Benefits of Auditing

✔ Automatic tracking of changes.
✔ Provides accountability and transparency.
✔ Useful for compliance and regulatory requirements.

Best Practices for Sensitive Data Auditing

✔ Audit only sensitive operations (balances, roles, passwords, permissions).
✔ Store who, what, when, where (IP/device).
✔ Don’t store raw sensitive data (e.g., passwords) → use masked/encrypted logs.
✔ Regularly review audit logs and set up alerts for suspicious activity.

Conclusion

Auditing sensitive data changes in Laravel gives you a second layer of defense beyond normal logging. By designing a custom auditing system, you can selectively monitor critical operations and ensure that your application is both secure and compliant.

Instead of tracking every model update, focus on what really matters—high-risk data changes that could affect users, finances, or security.

Fixing CORS Not Working in Laravel 12 (Custom Middleware Solution)

Mohamed Azmy — Tue, 05 Aug 2025 10:01:55 +0000

When working with Laravel 12 and building APIs consumed by frontend apps (like React, Vue, etc.), you might run into the dreaded CORS error — even when you think you’ve configured it correctly.

I did everything Laravel told me to do, but CORS was still broken. Eventually, I found a fix using custom middleware, and I’m sharing it here so you don’t waste hours like I did.

The Problem

I kept seeing this CORS error in the browser:

Access to fetch at 'http://example.com/api/...'
from origin 'http://localhost:3000'
has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

Even though I had this set in config/cors.php:

'paths' => ['api/*'],
'allowed_origins' => ['*'],
'supports_credentials' => true,

Nothing worked. Laravel’s built-in HandleCors middleware wasn’t doing its job.

The Solution (Custom Middleware)

Instead of relying on Laravel’s built-in CORS system, I created my own middleware and manually registered it.

Step 1: Create Middleware

php artisan make:middleware Cors

Then open the file at app/Http/Middleware/Cors.php and paste this:


<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

class Cors
{
    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);

        $response->header('Access-Control-Allow-Origin', '*');
        $response->header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
        $response->header('Access-Control-Allow-Headers', 'Origin, Content-Type, Accept, Authorization');

        return $response;
    }
}

Step 2: Register Middleware in Laravel 12

In Laravel 12,Http\Kernel.php is gone — so you register middleware in bootstrap/app.php instead.

If you want it applied globally to all requests:

$app->middleware([
    \App\Http\Middleware\Cors::class,
]);

If you want to apply it only to certain routes:

$app->routeMiddleware([
    'cors.custom' => \App\Http\Middleware\Cors::class,
]);

Step 3: Apply It to Routes (if route-based)

In your routes/api.php file:

Route::middleware(['cors.custom'])->group(function () {
    Route::get('/example', [ExampleController::class, 'index']);
});

Why This Works

Laravel’s default CORS middleware can sometimes silently fail due to misconfiguration or changes in the request flow. By taking full control with a custom middleware, you ensure the correct headers are returned with every response.

This is especially useful when:

You’re using Laravel 12’s minimal setup
You’re building SPAs or frontends on a different domain
The default config doesn’t work even after clearing caches

Final Thoughts

CORS issues are frustrating, and Laravel’s magic sometimes gets in the way. This manual solution worked for me and might help you too.

Let me know if this helped — or if you have a cleaner workaround!