DEV Community: Mohamed Fakhr

Designing Data-Intensive Applications

Mohamed Fakhr — Sun, 20 Sep 2026 19:04:23 +0000

Core Principles
This highlights three fundamental pillars:

Reliability

Tolerating hardware & software faults
Human error

Explanation:
A system is reliable if it keeps working correctly even when things go wrong.

This includes:

Server crashes or disk failures
Bugs in the code
Mistakes made by developers or users

Example: If a database node crashes, the system should still serve users without losing data.

Scalability

Measuring load & performance
Latency percentiles, throughput

Explanation:
Scalability is about handling growth (more users, more data, more requests).

Key ideas:

Load: How much work the system handles
Latency: How long requests take
Throughput: How many requests are processed

Example: Your app works fine with 1,000 users — can it handle 1 million?

Maintainability

Operability, simplicity & evolvability

Explanation:
Maintainability means the system is easy to:

Operate (monitor, debug, deploy)
Understand (clean code, clear structure)
Change (add features without breaking everything)

Example: A well-structured modular monolith (like what you’re building) is easier to maintain than messy, tightly coupled code.

When designing systems, you should always balance:

Reliability
Scalability
Maintainability

These are your “north star” principles.

Data-intensive means a system where data is the main challenge, not just the code or logic.

A data-intensive application is one that:

Handles large amounts of data
Focuses on storing, processing, and moving data efficiently
Cares a lot about the performance, scalability, and reliability of data

What makes an app “data-intensive”?

Large volume of data
Millions of users, records, or transactions
High read/write operations
Constant requests to the database
Data processing & transformation
Filtering, aggregating, and analyzing data
Data consistency & reliability matter
You can’t lose or corrupt data

Data-Intensive vs Compute-Intensive

Data-Intensive
Managing data (storage, DB, caching, scaling)

Compute-Intensive
Heavy calculations (AI, video rendering, scientific computing)

CDN (Content Delivery Network)

Mohamed Fakhr — Fri, 04 Sep 2026 13:14:08 +0000

What is a CDN?
It's a network of servers distributed in different locations around the world.

The CDN stores or caches static files such as:
Images
CSS
JavaScript
Videos
Fonts
PDFs

For example, imagine your project server is in Egypt:

            project Server
              🇪🇬 Egypt
                 │
      ┌──────────┼──────────┐
      ↓          ↓          ↓
    CDN        CDN        CDN
   🇩🇪         🇺🇸         🇸🇬
 Germany      USA       Singapore

Suppose you have:
Project Server
↓
/storage/products/iphone.jpg

Without CDN:
<img src="https://project-domain.com/storage/products/iphone.jpg">

The user in Germany requests the image:
Germany 🇩🇪
↓
Egypt 🇪🇬
↓
iphone.jpg
↓
Germany

Every request travels to your server.

With a CDN:

You configure a CDN, for example:
cdn.project-domain.com
Your image might become:
<img src="https://cdn.project-domain.com/products/iphone.jpg">

Now:
User 🇩🇪
↓
CDN 🇩🇪
↓
iphone.jpg

The image can be delivered from a server much closer to the user.

But where does the image come from initially?
This is the important part.

Suppose the image doesn't exist on the German CDN server yet.

The first request could work like:
User 🇩🇪
↓
CDN 🇩🇪
↓
"I don't have iphone.jpg"
↓
Project/Storage 🇪🇬
↓
iphone.jpg
↓
CDN 🇩🇪 ← cache it
↓
User

Then another user in Germany requests the same image:
User 🇩🇪
↓
CDN 🇩🇪
↓
iphone.jpg ✅

The request doesn't need to go back to your project server.

That's one of the biggest benefits.

Another approach: Object Storage + CDN

For a modern application, you might have:

Your Project
│
↓
Amazon S3 / Azure Blob Storage
│
↓
CDN
│
↓
Users

For example:

Your Project
↓
S3
↓
CloudFront
↓
Users

Your application uploads:
iphone.jpg
to S3.

The CDN delivers it to users.

This is especially useful when you have millions of images because you don't need to store all those images on your application server.

Why do we use a CDN?

Faster
The user gets the content from a nearby server.
Less load on your project
Instead of:
10,000 users
↓
Project Server

You can have:
10,000 users
↓
CDN
↓
Project only when necessary

Better scalability Your Project server focuses on: API Business Logic Database Authentication Orders Payments

while the CDN handles:
Images
CSS
JS
Videos
Static files

Protection Many CDN providers also provide things like: DDoS protection Caching WAF TLS/HTTPS Rate limiting One important distinction

SaaS (Software as a Service)

Mohamed Fakhr — Sat, 29 Aug 2026 15:06:10 +0000

When building a SaaS (Software as a Service) project, the database architecture is one of the most important decisions.
There are two common approaches to multi‑tenant SaaS database design:

Option 1:
One database per client (separate database per tenant)
How it works:
Each client (tenant) gets their own database.

Your application (same codebase) connects dynamically to the tenant’s database based on their domain, subdomain, or login.

Pros:

Strong data isolation – clients’ data is completely separated.
Easier to migrate/export data or comply with regulations (e.g., GDPR).
Less risk that a bug or query exposes other tenants’ data.
You can scale some clients separately if needed (e.g., move a big client’s DB to a bigger server).

Cons:

Harder to manage upgrades or schema changes (you must migrate many databases).
Higher infrastructure cost (many DB instances).
More complex DevOps (backups, monitoring, migrations for each DB).

Option 2:
All clients share the same database (single database, multi‑tenant)
How it works:
One database contains all tenants’ data.

Every table that stores tenant-specific data has a tenant_id (or company_id) column to separate data logically.

Pros:

Easier to manage (only one DB schema to upgrade).
Cheaper to host (one DB server).
Easier to run analytics across tenants.
Simpler CI/CD pipeline.

Cons:

Security risk if not done carefully – you must always filter by tenant_id in every query, otherwise data leaks between tenants.
Harder to export one client’s data separately.
A large single DB can become a bottleneck if you have thousands of tenants.

What to consider if using a single database:

Add tenant_id to all tenant-specific tables.
Apply row-level security or strict query filters (e.g., in Laravel use global scopes or middleware).
Use indexes on tenant_id to keep queries fast.
Be careful with shared tables (like product catalog) vs tenant-specific tables (like orders).
Backups: you’re backing up everyone’s data together, so plan recovery carefully.
Scaling: eventually you may need read replicas, sharding by tenant_id, or moving heavy tenants to their own DB.

Which one should you choose:

If you expect a few big enterprise clients that might demand strict isolation or their own backups → use separate databases per client.
If you expect many small clients (e.g., hundreds/thousands of small shops) → use one shared database with tenant_id (multi‑tenant).

Single DB:

Add tenant_id to tables.
Use middleware to set where('tenant_id', $tenantId) globally.

Multi DB:

Have a tenants table in a main DB storing DB connection info (host, username, password).
On request, resolve the tenant and dynamically set the DB connection (using DB::purge() / DB::reconnect()).

Laravel Application Optimization

Mohamed Fakhr — Mon, 24 Aug 2026 17:46:52 +0000

A. Database & Eloquent Optimization
1- Eager Loading (N+1 Problem):
Avoid the N+1 query problem by eager loading relationships when querying models.
Bad (N+1):

$posts = App\Models\Post::all();
foreach ($posts as $post) {
    echo $post->user->name; // Each user call is a new query
}

Good (Eager Loading):

$posts = App\Models\Post::with('user')->get();
foreach ($posts as $post) {
    echo $post->user->name; // Only 2 queries (Post + User)
}

2- Select Specific Columns:
Don't select all columns select('*') if you only need a few.
$users = User::select('id', 'name', 'email')->get();

3- Use Indexes:
Ensure your database columns that are frequently used in WHERE, JOIN, ORDER BY clauses have proper indexes.
Add indexes in your migrations:

$table->string('email')->unique(); // Unique automatically creates an index
$table->index('category_id'); // Custom index

4- Pagination for Large Datasets:
Never load all records if you have a large table. Use paginate() or simplePaginate().

 $users = User::paginate(15);

5- chunk() for Processing Large Datasets:
When processing many records (e.g., for background jobs), use chunk() or cursor() to avoid loading all records into memory at once.

Post::chunk(200, function ($posts) {
      foreach ($posts as $post) {
          // Process post
      }
  });

6- exists() instead of count() for existence checks:
If you just need to know if a record exists, exists() is more efficient than count() as it stops at the first match.

if (User::where('email', $email)->exists()) 
{ /* ... */ }

B. Caching
1- Route Caching:
If you have many routes, caching them significantly speeds up route registration.
Run in production: php artisan route:cache
Remember to clear it php artisan route:clear and re-cache after any route changes.
2- Configuration Caching:
Combines all your configuration files into a single file for faster loading.
Run in production: php artisan config:cache
Clear php artisan config:clear and re-cache after config changes.
3- View Caching:
Caches your Blade compiled views, so they don't have to be recompiled on every request.
Run in production: php artisan view:cache
Clear php artisan view:clear after view changes.
4- Application Data Caching:
Cache frequently accessed data that doesn't change often (e.g., settings, categories, static content).
Use Cache::remember(), Cache::put(), Cache::get() with a suitable driver (Redis or Memcached are much faster than file-based).

C. Queues (Background Processing)
Offload Heavy Tasks:
Move time-consuming tasks (email sending, image processing, video encoding, complex calculations, third-party API calls) to background queues.
This allows your web requests to return a response quickly, improving user experience.
Example:
Instead of:
Mail::to($user->email)->send(new WelcomeEmail($user));
Use a job:
dispatch(new App\Jobs\SendWelcomeEmail($user));
Remember to configure a queue driver (e.g., database, redis, sqs) and run a queue worker php artisan queue:work.

D. Asset Optimization
1- CDN (Content Delivery Network):
Serve static assets (images, CSS, JS) from a CDN to reduce latency for users geographically distant from your server.
2- Image Optimization:
Compress images before deploying. (using tools like TinyPNG, ImageOptim, or build tools)
3- Minification:
Combine multiple CSS files into one and multiple JS files into one.
Minify CSS and JavaScript to remove whitespace and comments.

E. PHP & Server Environment
1- Use the Latest PHP Version:
Always use the latest stable PHP version. Each new version brings significant performance improvements.
2- Enable OPcache:
OPcache is a PHP extension that caches precompiled script bytecode in memory, avoiding the parsing and compilation on every request. It's crucial for PHP application performance.
Ensure it's enabled and configured correctly in your php.ini.
3- Composer Optimization:
In production, install Composer dependencies without dev dependencies:
composer install --no-dev --optimize-autoloader --optimize-autoloader builds a faster class map.
4- JIT Compiler (PHP 8+):
PHP 8's JIT (Just-In-Time) compiler can provide significant performance boosts for CPU-bound tasks.
Ensure it's enabled and configured in php.ini if your workload can benefit from it.
5- HTTP/2 and GZIP Compression:
Configure your web server (Nginx or Apache) to use HTTP/2 and GZIP compression.
HTTP/2: Allows multiple requests/responses over a single connection, reducing latency.
GZIP Compression: Compresses text-based assets (HTML, CSS, JS) before sending them to the client, reducing bandwidth usage.
6- Proper Server Configuration:
Use a fast web server like Nginx (preferred over Apache for performance).
Tune PHP-FPM settings (e.g., pm.max_children, pm.start_servers) based on your server's resources and traffic.
7- Choose a Good Hosting Provider:
A cheap, overloaded shared host will negate many of your optimization efforts. Invest in a good VPS or dedicated server.

F. Code Quality & Best Practices:
1- Remove Unused Packages & Services:
Audit your composer.json and config/app.php. Remove any packages or service providers you don't actually need.
2- Limit Middleware Usage:
Middleware adds overhead. Only apply middleware where absolutely necessary.
3- Don't Use APP_DEBUG=true in Production:
This is a major performance killer. Set APP_DEBUG=false in your .env for production.
4- Minimize Logging:
Adjust LOG_LEVEL in production (e.g., warning or error) to reduce disk I/O from excessive logging.

Security Features in Laravel

Mohamed Fakhr — Sun, 23 Aug 2026 18:11:04 +0000

1- Authentication
Laravel offers a complete authentication system that can be customized to fit your needs. The built-in Auth facade provides methods to manage user registration, login, logout, password reset, and email verification.

use Illuminate\Support\Facades\Auth;

// Check if the user is authenticated
if (Auth::check()) {
    // The user is logged in
}

2- Authorization
Laravel includes a simple and easy-to-use authorization system. You can use policies and gates to control user access to various parts of your application.

Using policy:

// Create a policy
php artisan make:policy PostPolicy

// Register the policy in AuthServiceProvider
protected $policies = [
    'App\Models\Post' => 'App\Policies\PostPolicy',
];

// Define a method in PostPolicy
public function update(User $user, Post $post)
{
    return $user->id === $post->user_id;
}

Using gates:

use Illuminate\Support\Facades\Gate;

Gate::define('update-post', function ($user, $post) {
    return $user->id == $post->user_id;
});

if (Gate::allows('update-post', $post)) {
    // The user can update the post
}

3- CSRF Protection
Laravel automatically generates a CSRF token for each active user session managed by the application. This token is used to verify that the authenticated user is the one actually making the requests to the application.

In HTML forms:

  <form method="POST" action="/example">
      @csrf
      <!-- Your form inputs here -->
  </form>

4- Hashing
Laravel provides a secure way to hash passwords using the Hash facade.

Usage:

use Illuminate\Support\Facades\Hash;

// Hashing a password
$hashedPassword = Hash::make('password');

// Checking a password against a hash
if (Hash::check('password', $hashedPassword)) {
    // The passwords match...
}

5- Input Validation
Laravel provides a powerful validation mechanism to ensure that the data received from the user is valid before it is processed.

Usage:

use Illuminate\Http\Request;

public function store(Request $request)
{
    $validated = $request->validate([
        'title' => 'required|max:255',
        'body' => 'required',
    ]);

    // The data is valid...
}

6- SQL Injection Protection
By using Eloquent ORM or the query builder, Laravel protects your application from SQL injection attacks.

Usage:

// Using Eloquent ORM
$user = User::where('email', $email)->first();

// Using query builder
$user = DB::table('users')->where('email', $email)->first();

7- XSS Protection
Laravel automatically escapes data that is output in views to prevent cross-site scripting (XSS) attacks.

Usage: Blade

<!-- Blade template -->
{{ $userInput }} <!-- This will be escaped -->
{!! $userInput !!} <!-- This will not be escaped -->

8- Rate Limiting
Laravel provides rate limiting to prevent abuse of your application by limiting the number of requests a user can make to your application.

Usage:

use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('global', function (Request $request) {
    return Limit::perMinute(60);
});

9- File Upload Security
When handling file uploads, Laravel provides methods to ensure that the uploaded files are of expected types and sizes.

Usage:

$request->validate([
    'photo' => 'required|file|mimes:jpeg,png,jpg,gif|max:2048',
]);

Best Practices:

Always use the latest version of Laravel to ensure you have the latest security updates.
Regularly update your dependencies using Composer.
Use environment variables to manage sensitive information.
Set proper permissions on your server to restrict access to files and directories.
Regularly back up your data and test your backup strategy.
Monitor and log your application for unusual activity and sensitive actions.

RESTful APIs

Mohamed Fakhr — Sat, 15 Aug 2026 22:05:11 +0000

First, what is the difference between RESTful APIs and REST APIs?
REST API:

Used for simple projects and doesn't require a complex system.
It offers flexibility and is easy to implement, especially for smaller applications or quick prototypes.
Based on REST principles, but not strictly following all constraints.
Might use POST or GET for all data transfers.
Can represent resources in various formats (XML, JSON, HTML, etc.)
Can be flexible and varied (e.g., /deleteUser?id=5).

RESTful APIs:

Used for large-scale, Complex Applications.
For performance and scalability if the project requires optimized performance with high scalability and handles large volumes of data and high traffic.
Strictly according to REST standards.
Strictly uses HTTP methods in a RESTful manner (GET, POST, PUT, DELETE)
Follows a uniform format for resources, typically JSON or XML
Uses a standardized and uniform URL structure (e.g., DELETE /users/5).

Representational state transfer (REST) is a set of architectural principles that define how to build application programming interfaces (APIs), which allow data to be communicated between web applications.

When a request for data is sent to a REST API, it’s usually done through hypertext transfer protocol (commonly referred to as HTTP).
Once a request is received, APIs designed for REST (called RESTful APIs or RESTful web services) can return messages in a variety of formats: HTML, XML, plain text, and JSON.
In this way, RESTful APIs are more flexible and can be easier to set up.

Note: JSON (JavaScript Object Notation) is favored as a message format because it can be read by any programming language, is human- and machine-readable, and is lightweight.

REST supports all HTTP methods: GET, POST, PUT & DELETE.
GET: Retrieve particular resources by an ID
POST: Create a new resource.
PUT: Update a particular resource by an ID.
DELETE: Remove a particular resource.

Note about PUT & PATCH:
PUT is used when you have all the updated data, while PATCH is suitable for partial updates.

Laravel Eloquent ORM (Object-Relational Mapper) Relationships

Mohamed Fakhr — Thu, 13 Aug 2026 10:21:05 +0000

One-to-One Relationship:

users
id - integer
name - string

phones
id - integer
user_id - integer

In the User model:

public function phone()
{
   return $this->hasOne(Phone::class);
}

In the Phone model:

public function user()
{
   return $this->belongsTo(User::class);
}

One-to-Many Relationship:

posts
id - integer
name - string

comments
id - integer
post_id - integer

In the Post model:

public function comments()
{
     return $this->hasMany(Comment::class);
}

In the Comment model:

public function post()
{
        return $this->belongsTo(Post::class);
}

Many-to-many Relationship:

users
id - integer
name - string

roles
id - integer
name - string

role_user (Pivot table)
user_id - integer
role_id - integer

In User model

public function roles()
{
    return $this->belongsToMany(Role::class, 'role_user');
}

In Role model:

public function users()
{
     return $this->belongsToMany(User::class, 'role_user');
}

Important Note:

The pivot table is always singular; if you give it another name, make it plural.
The name of the pivot table is ordered alphabetically.
If the pivot table has more than two foreign keys, you use it as a normal table and create a model for it.

One-to-One (Polymorphic):
posts
id - integer
name - string

users
id - integer
name - string

images
id - integer
url - string
imageable_id - integer
imageable_type - string

In the Image model

public function imageable(): MorphTo
{
     return $this->morphTo();
}

In the User model:

public function image(): MorphOne
{
    return $this->morphOne(Image::class, 'imageable');
}

In the Post model:

public function image(): MorphOne
{
    return $this->morphOne(Image::class, 'imageable');
}

One-to-Many (Polymorphic):
posts
id - integer
title - string
body - text

videos
id - integer
title - string
url - string

comments
id - integer
body - text
commentable_id - integer
commentable_type - string

In the Comment model:

public function commentable(): MorphTo
{
      return $this->morphTo();
}

In the Video model:

public function comments(): MorphOne
{
     return $this->morphMany(Comment::class, 'commentable');
}

In the Post model:

public function comments(): MorphOne
{
    return $this->morphMany(Comment::class, 'commentable');
}

Many-to-Many (Polymorphic):
posts
id - integer
name - string

videos
id - integer
name - string

tags
id - integer
name - string

taggables
tag_id - integer
taggable_id - integer
taggable_type - string

In the Tag model:

public function videos(): MorphToMany
{
      return $this->morphedByMany(Video::class, 'taggable');
}

public function posts(): MorphToMany
{
     return $this->morphedByMany(Post::class, 'taggable');
}

In the Video model:

public function tags(): MorphToMany
{
     return $this->morphToMany(Tag::class, 'taggable');
}

In the Post model:

public function tags(): MorphToMany
{
     return $this->morphToMany(Tag::class, 'taggable');
}

Has One Through Relationship:
The "has-one-through" relationship defines a one-to-one relationship with another model.
mechanics
id - integer
name - string

cars
id - integer
model - string
mechanic_id - integer

owners
id - integer
name - string
car_id - integer

In the Mechanic Model:

public function carOwner(): HasOneThrough
{
   return $this->hasOneThrough(Owner::class, Car::class);
}

Has Many Through Relationship:
The "has-many-through" relationship defines a many-to-many relationship with another model.
projects
id - integer
name - string

environments
id - integer
project_id - integer
name - string

deployments
id - integer
environment_id - integer
commit_hash - string

In the Project Model:

public function deployments(): HasManyThrough
{
    return $this->hasManyThrough(Deployment::class, Environment::class);
}

Choosing between Eloquent ORM and Query Builder:

Use Eloquent when you:

Want readable, expressive, object-oriented code.
Are working with relationships (hasMany, belongsTo, etc.).
Want to take advantage of features like accessors/mutators, events, casts, etc.
Don’t need extreme query performance.

Use Query Builder when:

You need complex joins, groupings, aggregates.
You care more about raw performance.
You don’t need to manipulate model objects (e.g., User model).
You’re building reports, analytics, or API endpoints returning raw JSON.
You still get Laravel’s database abstraction and security (no SQL injection risk).

OOP Object-Oriented Programming

Mohamed Fakhr — Tue, 11 Aug 2026 18:35:31 +0000

Advantages of using OOP:

Is faster and easier to execute.
Provides a clear structure for the programs.
Helps to keep code DRY "Don't Repeat Yourself" and makes code easier to maintain, modify, and debug.
Makes it possible to create fully reusable applications with less code and shorter development time.

Define a Class:
A class is defined by using the class keyword, followed by the name of the class and a pair of curly braces {}. All its properties and methods go inside the braces.

Delegation:
Delegation means that you use an object of another class as an instance variable.
We can create multiple objects from a class. Each object has all the variables and functions defined in the class. An object of a class is made using the new keyword.

Note:
The $this keyword refers to the current class and is only available inside methods.

__construct() function:
Automatically runs at the beginning of the class.

__destruct() function:
Automatically runs at the end of the class.

Encapsulation:
The wrapping up of data and methods is a protection mechanism for the variables and functions inside the class.

Access Modifier:
Public: Variables or functions can be accessed from everywhere.

Private: Variables or functions can ONLY be accessed inside the class.

Protected: Variables or functions can be accessed inside the class and by child classes that extend from the parent class.

Constants:

It can’t be changed once it is declared.
Declared inside a class with the const keyword.
It is recommended to name the constants in all uppercase letters.
Access outside the class by using the class name followed by the scope resolution operator ::.
Access a constant inside the class by using the self keyword.

Static Functions and Variables:

Static functions or variables can be called directly - without creating an instance of the class first.
Static functions or variables are declared with the static keyword.
To access a static function or variable, use the class name, double colon ::, and the function name.
A static function can be accessed from a function in the same class using the self keyword and double colon ::.
To call a static method from a child class, use the parent keyword inside the child class.
The static method can be public or protected.

Note:
The final keyword can be used to prevent class inheritance or to prevent method overriding.

Polymorphism:
is one of the OOP features that allows us to perform a single action in different ways.
Like declaring a function in the parent class and giving the function a different implementation in the children's classes.

Abstract:

Can have both abstract methods (without body) and regular methods (with implementation).
Can have properties (variables).
A class can extended single abstract (single inheritance).
Cannot be instantiated directly — only extended (inherited) by other classes.
Used when classes share some common behavior, but also need to implement some parts individually.

Interface:

Can only contain method declarations (no implementation).
No properties — only method signatures.
A class can implement multiple interfaces (multiple inheritance).
Forces the class to implement all methods defined in the interface.

Traits
PHP only supports single inheritance: a child class can inherit from only one parent.
So, what if a class needs to inherit multiple behaviors?
OOP traits solve this problem.

Traits are used to declare functions that can be used in multiple classes. Traits can have functions and abstract functions that can be used in multiple classes, and the functions can have any access modifier (public, private, or protected).
Traits are declared with the trait keyword.
To use a trait in a class, use the use keyword.

Difference between Traits and Interfaces in PHP
many classes implement the same interface but have different behavior, while traits are just chunks of code injected into a class in PHP.

SOLID Principles

Mohamed Fakhr — Wed, 29 Jul 2026 18:29:36 +0000

S for Single Responsibility
Mistake:
Fat Controllers and Models
Developers often cram too much logic into controllers and models, making them hard to maintain and test.
Solution:
Suggests that a class should have only one reason to change, meaning each class should only have one responsibility.
O for Open–Closed
Mistake:
Modifying existing code to add new functionality
Developers sometimes directly modify existing classes to add new features, which can introduce bugs and make the code harder to maintain.
Solution:
States that software entities should be open for extension but closed for modification.
L for Liskov Substitution
Mistake:
Subclasses that do not adhere to the contract of their base classes
Developers may create subclasses that override base-class methods in ways that change their expected behavior, leading to bugs.
Solution:
States that subclasses should be substitutable for their base classes without altering the correctness of the program. Ensure that subclasses override methods in a manner consistent with the base class.
Example:
Violation of LS

class Bird
{
    public function fly()
    {
        // Fly logic
    }
}

class Penguin extends Bird
{
    public function fly()
    {
        throw new Exception("Penguins can't fly");
    }
}

Adhering to LS

interface Bird
{
    public function move();
}

class FlyingBird implements Bird
{
    public function move()
    {
        // Fly logic
    }
}

class Penguin implements Bird
{
    public function move()
    {
        // Swim logic
    }
}

I for Interface Segregation
Mistake:
Implementing large interfaces
Developers sometimes create large interfaces with methods that implementing classes don't need, leading to unused code.
Solution:
Suggests that clients should not be forced to depend on interfaces they do not use. Create smaller, more specific interfaces.
D for Dependency Inversion
Mistake:
High-level modules depending on low-level modules
Developers often make high-level classes depend directly on low-level classes, which makes the code rigid and hard to change.
Solution:
States that high-level modules should not depend on low-level modules, but both should depend on abstractions. Use dependency injection to adhere to DIP.
Example:
Violation of DIP

class MySQLConnection
{
    public function connect()
    {
        // Connection logic
    }
}

class UserRepository
{
    protected $dbConnection;

    public function __construct()
    {
        $this->dbConnection = new MySQLConnection();
    }
}

Adhering to DIP

interface DBConnectionInterface
{
    public function connect();
}

class MySQLConnection implements DBConnectionInterface
{
    public function connect()
    {
        // Connection logic
    }
}

class UserRepository
{
    protected $dbConnection;

    public function __construct(DBConnectionInterface $dbConnection)
    {
        $this->dbConnection = $dbConnection;
    }

    public function getConnectionStatus()
    {
        return $this->dbConnection->connect();
    }
}

In Controller

$connection = new MySQLConnection();
$connection = new PostgreSQLConnection();

$userRepo = new UserRepository($connection);

// Call connect via UserRepository
echo $userRepo->getConnectionStatus();

Service Container

Mohamed Fakhr — Tue, 28 Jul 2026 12:02:32 +0000

The Service Container is one of Laravel's core features. It is Laravel's implementation of the Dependency Injection (DI) and Inversion of Control (IoC) patterns.
It's also Laravel's way of managing dependencies and injecting them automatically.
Instead of creating dependencies manually with the new keyword, you let the container resolve and inject them for you.

How Laravel Uses the Service Container

Most Service Container bindings are registered inside Service Providers using the register() method.
Within a service provider, you have access to the container through the $this->app property.

class AppServiceProvider extends ServiceProvider
{
     public function register(): void
     {
        //
     }
}

Use the bind() method to tell Laravel how to create an object. Every time the dependency is resolved, Laravel creates a new instance.

Exaple
Whenever someone requests LoggerInterface, Laravel should create and return a new FileLogger instance.

$this->app->bind(LoggerInterface::class, function () {
    return new FileLogger();
});

Use singleton() when you want Laravel to create only one instance and reuse it throughout the application's lifetime.

Exaple
The first time CacheService is requested, Laravel creates the object.
Every subsequent request returns the same instance instead of creating a new one.

$this->app->singleton(CacheService::class, function () {
    return new CacheService();
});

$one = app(CacheService::class);
$two = app(CacheService::class);
var_dump($one === $two); // true

bind() vs singleton()
bind(): Creates a new instance every time the dependency is resolved.
singleton(): Creates one instance and reuses it for all future resolutions.

Note:

You will typically be interacting with the container within service providers; however, if you would like to interact with the container outside of a service provider, you may do so via the App facade
There is no need to bind classes into the container if they do not depend on any interfaces. The container does not need to be instructed on how to build these objects, since it can automatically resolve these objects using reflection.

Exaple
If your class has no constructor parameters (or only concrete classes, not interfaces), Laravel will automatically create it — you don’t have to register it.

class HelloService {
    public function sayHello() {
        return 'Hello!';
    }
}
$service = app(HelloService::class);

Compiled and Interpreted Languages

Mohamed Fakhr — Wed, 22 Jul 2026 11:23:54 +0000

The key difference lies in how the code is executed:

Compiled Languages:
The source code is translated into machine code by a compiler.it's a sequence of instructions the computer's CPU can directly understand. This process happens before the program is executed. The resulting machine code is then executed directly by the CPU.
Translation: Translated into machine code before execution
Execution: Generally faster
Debugging: Can be more difficult as errors may not be immediately apparent.
Examples: C, C++, Java, Go

Interpreted Languages:
The source code is executed line by line by an interpreter. The interpreter reads each line, translates it into machine code, and then executes it immediately.
Translation: Translated and executed line by line
Execution: Generally slower
Examples: Python, JavaScript, PHP, Ruby

PHP: PHP is primarily an interpreted language.
However, some PHP engines (like the popular PHP-FPM) use techniques like "just-in-time" (JIT) compilation to improve performance. JIT compilers translate parts of the PHP code into machine code during execution, which can significantly speed up performance.

In essence:

Compiled languages prioritize performance and efficiency, while interpreted languages prioritize ease of development and portability.
The choice between a compiled and interpreted language depends on the specific needs of the project.

Stateful vs Stateless Authentication

Mohamed Fakhr — Mon, 20 Jul 2026 12:38:38 +0000

Stateful Authentication
Session-based: Relies on server-side sessions to maintain user state.
How it works: When a user logs in, a session is created on the server, and a session ID is stored in a cookie on the client. Subsequent requests include the session ID, allowing the server to identify the user.
Advantages: Simple to implement, good for traditional web applications.
Disadvantages: Scalability issues with large user bases, vulnerability to session hijacking, and state management complexity.

Stateless Authentication
Token-based: Relies on tokens (usually JWTs) instead of sessions.
How it works: After successful authentication, a JWT containing user information is issued. Subsequent requests include the token in the authorization header. The server validates the token without maintaining user state.
Advantages: Scalability, security, and flexibility.
Disadvantages: Increased complexity in token management and potential for larger payloads.

When to Use Which
Stateful Authentication: Suitable for traditional web applications where user experience is prioritized and scalability is not a major concern.

Stateless Authentication: Ideal for APIs, mobile applications, and single-page applications (SPAs) where scalability, security, and statelessness are essential.