Cara Membangun Multitenancy Architecture untuk SaaS B2B Indonesia

Membangun aplikasi SaaS (Software as a Service) B2B di Indonesia sedang menjadi peluang emas bagi developer dan entrepreneur digital.

Namun ada satu tantangan teknis yang sering membuat bingung: bagaimana mengelola data ratusan atau ribuan klien dalam satu aplikasi dengan aman dan efisien?

Jawabannya adalah multitenancy architecture—sebuah pola arsitektur yang memungkinkan satu instance aplikasi melayani banyak tenant (klien) sekaligus.

Artikel ini akan membahas cara membangun multitenancy architecture yang tepat untuk SaaS B2B di Indonesia, mulai dari strategi isolasi data hingga implementasi teknis yang proven di production.

Apa Itu Multitenancy dan Mengapa Penting untuk SaaS B2B?

Multitenancy adalah arsitektur software di mana satu instance aplikasi melayani banyak tenant (organisasi/klien) dengan data yang terisolasi satu sama lain.

Bayangkan aplikasi HR management untuk perusahaan—PT ABC dan PT XYZ menggunakan aplikasi yang sama, tetapi data karyawan mereka tidak boleh tercampur.

Berbeda dengan single-tenancy di mana setiap klien mendapat instance aplikasi terpisah, multitenancy lebih efisien dalam resource dan biaya operasional.

Untuk SaaS B2B di Indonesia, multitenancy sangat penting karena:

• Biaya server dan maintenance lebih rendah—satu infrastruktur untuk semua tenant
• Update dan bug fix langsung berlaku untuk semua klien tanpa deploy berkali-kali
• Scalability lebih mudah—tinggal tambah resource tanpa setup instance baru
• Time to market lebih cepat untuk onboarding klien baru

Tapi tantangannya adalah bagaimana menjamin isolasi data antar tenant tetap aman dan performa tetap optimal saat jumlah tenant bertambah.

Tiga Strategi Database Multitenancy yang Wajib Dipahami

Ada tiga pendekatan utama dalam mendesain database multitenancy, masing-masing dengan trade-off berbeda.

1. Database Per Tenant (Isolated Database)

Setiap tenant mendapat database terpisah dengan schema identik.

Contoh: tenant_abc.users, tenant_xyz.users—database berbeda tapi struktur tabel sama.

Keuntungan pendekatan ini adalah isolasi paling kuat, backup/restore per tenant mudah, dan migrasi tenant ke server lain simpel.

Kelemahannya adalah overhead maintenance tinggi saat kelola ratusan database, dan biaya storage lebih besar.

Cocok untuk SaaS enterprise dengan kebutuhan compliance ketat atau tenant yang butuh dedicated resources.

2. Schema Per Tenant (Shared Database)

Semua tenant dalam satu database, tapi setiap tenant punya schema sendiri.

Contoh: public.abc_users, public.xyz_users dalam database yang sama.

Pendekatan ini memberikan balance antara isolasi dan efisiensi—lebih mudah maintain dibanding database terpisah, tapi tetap ada logical separation.

Query harus selalu specify schema untuk menghindari data leakage antar tenant.

Cocok untuk SaaS mid-market dengan jumlah tenant puluhan hingga ratusan.

3. Shared Database with Row-Level Tenant ID

Semua tenant dalam satu database dan satu schema, dipisahkan dengan kolom tenant_id di setiap tabel.

Contoh: tabel users dengan kolom tenant_id—semua data tenant tercampur tapi filtered berdasarkan ID.

Ini pendekatan paling efisien dari segi resource dan paling mudah untuk scale horizontal.

Risikonya adalah jika ada bug di query filtering, data bisa bocor antar tenant—security harus extra ketat.

Cocok untuk SaaS dengan jumlah tenant sangat banyak (ribuan) dan data per tenant tidak terlalu besar.

Butuh jasa pembuatan website profesional? KerjaKode menyediakan layanan pembuatan website berkualitas tinggi dengan harga terjangkau. Kunjungi jasa pembuatan website KerjaKode untuk konsultasi gratis dan wujudkan website impian Anda.

Implementasi Row-Level Multitenancy di Laravel

Mari kita fokus ke pendekatan shared database dengan row-level tenant ID karena ini yang paling populer untuk SaaS modern.

Berikut langkah implementasi di Laravel yang aman dan maintainable.

Setup Tenant Identification

Pertama, buat middleware untuk identifikasi tenant dari subdomain atau custom domain.

// app/Http/Middleware/IdentifyTenant.php
namespace App\Http\Middleware;

use Closure;
use App\Models\Tenant;
use Illuminate\Support\Facades\Cache;

class IdentifyTenant
{
    public function handle($request, Closure $next)
    {
        $host = $request->getHost();
        
        // Extract subdomain (abc.yourapp.com)
        $subdomain = explode('.', $host)[0];
        
        // Cache tenant lookup untuk performa
        $tenant = Cache::remember("tenant_{$subdomain}", 3600, function() use ($subdomain) {
            return Tenant::where('subdomain', $subdomain)
                ->orWhere('custom_domain', $host)
                ->first();
        });
        
        if (!$tenant) {
            abort(404, 'Tenant not found');
        }
        
        // Set tenant ke app container
        app()->instance('tenant', $tenant);
        
        return $next($request);
    }
}

Middleware ini mengekstrak subdomain dari URL dan meload data tenant dari database dengan caching untuk performa.

Global Scope untuk Auto-Filter Tenant

Buat global scope yang otomatis menambahkan WHERE tenant_id ke semua query.

// app/Models/Scopes/TenantScope.php
namespace App\Models\Scopes;

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Scope;

class TenantScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        if (app()->has('tenant')) {
            $builder->where('tenant_id', app('tenant')->id);
        }
    }
}

Kemudian buat trait untuk apply scope ini ke semua model yang perlu tenant filtering.

// app/Models/Traits/BelongsToTenant.php
namespace App\Models\Traits;

use App\Models\Scopes\TenantScope;

trait BelongsToTenant
{
    protected static function bootBelongsToTenant()
    {
        static::addGlobalScope(new TenantScope);
        
        // Auto-set tenant_id saat create
        static::creating(function ($model) {
            if (app()->has('tenant') && !$model->tenant_id) {
                $model->tenant_id = app('tenant')->id;
            }
        });
    }
}

Sekarang tinggal gunakan trait ini di model yang butuh tenant isolation.

// app/Models/User.php
namespace App\Models;

use App\Models\Traits\BelongsToTenant;
use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    use BelongsToTenant;
    
    protected $fillable = ['tenant_id', 'name', 'email', 'password'];
}

Dengan setup ini, semua query User otomatis di-filter berdasarkan tenant yang sedang login.

User::all() hanya akan return user dari tenant saat ini tanpa perlu WHERE manual.

Mengelola Database Migration untuk Multitenancy

Migration di aplikasi multitenant harus dirancang dengan hati-hati agar tidak break data existing tenant.

Setiap tabel yang tenant-specific harus punya kolom tenant_id dengan index.

// database/migrations/xxxx_create_users_table.php
Schema::create('users', function (Blueprint $table) {
    $table->id();
    $table->foreignId('tenant_id')->constrained()->onDelete('cascade');
    $table->string('name');
    $table->string('email');
    $table->string('password');
    $table->timestamps();
    
    // Composite index untuk query performance
    $table->index(['tenant_id', 'email']);
    $table->unique(['tenant_id', 'email']);
});

Perhatikan unique constraint pada kombinasi tenant_id dan email—ini memastikan email unik per tenant, bukan global.

Untuk tabel reference yang shared antar tenant (seperti countries, categories), jangan tambahkan tenant_id.

Strategi Authentication dan Authorization

Authentication di multitenancy lebih kompleks karena harus memvalidasi user dan tenant sekaligus.

User dengan email yang sama bisa exist di multiple tenant dengan password berbeda.

Customize Laravel authentication untuk meng-scope credential check ke tenant saat ini.

// app/Http/Controllers/Auth/LoginController.php
protected function credentials(Request $request)
{
    return [
        'email' => $request->email,
        'password' => $request->password,
        'tenant_id' => app('tenant')->id,
    ];
}

Untuk authorization, gunakan policy dengan tenant context.

// app/Policies/PostPolicy.php
public function update(User $user, Post $post)
{
    // Auto-verified karena global scope
    // Tapi tetap check ownership
    return $user->id === $post->user_id;
}

Karena global scope sudah memastikan $post adalah milik tenant saat ini, kita hanya perlu check ownership level user.

Handling Tenant-Specific Configuration

Setiap tenant sering butuh konfigurasi berbeda—logo, warna brand, email settings, payment gateway, dll.

Simpan config ini di tabel tenant_settings dengan struktur key-value atau JSON.

// app/Models/Tenant.php
class Tenant extends Model
{
    protected $casts = [
        'settings' => 'array',
    ];
    
    public function getSetting($key, $default = null)
    {
        return data_get($this->settings, $key, $default);
    }
    
    public function setSetting($key, $value)
    {
        $settings = $this->settings ?? [];
        data_set($settings, $key, $value);
        $this->settings = $settings;
        $this->save();
    }
}

Di view, akses setting tenant dengan helper function.

// app/Helpers/tenant.php
function tenant_setting($key, $default = null)
{
    return app('tenant')->getSetting($key, $default);
}

// Usage di blade
<img src="{{ tenant_setting('logo_url') }}" alt="Logo">
<style>
    :root {
        --primary-color: {{ tenant_setting('brand_color', '#3490dc') }};
    }
</style>

Optimasi Performa dengan Caching Strategy

Multitenancy menambah overhead query karena setiap query butuh WHERE tenant_id.

Gunakan caching yang tenant-aware untuk mengurangi load database.

// Cache key harus include tenant_id
$cacheKey = "tenant_" . app('tenant')->id . "_users_list";

$users = Cache::remember($cacheKey, 3600, function() {
    return User::with('roles')->get();
});

Untuk invalidasi cache saat data berubah, gunakan observer yang auto-clear cache tenant-specific.

// app/Observers/UserObserver.php
class UserObserver
{
    public function saved(User $user)
    {
        $this->clearTenantCache($user->tenant_id);
    }
    
    protected function clearTenantCache($tenantId)
    {
        $pattern = "tenant_{$tenantId}_*";
        // Clear semua cache dengan pattern ini
        Cache::flush(); // Atau gunakan Redis SCAN untuk lebih specific
    }
}

Database Query Monitoring dan Optimization

Monitor query performance per tenant untuk detect masalah early.

Tenant dengan data besar bisa memperlambat query jika index tidak optimal.

Log slow query dengan context tenant_id untuk troubleshooting.

// app/Providers/AppServiceProvider.php
public function boot()
{
    DB::listen(function ($query) {
        if ($query->time > 1000) { // Query lebih dari 1 detik
            Log::warning('Slow Query Detected', [
                'tenant_id' => app('tenant')->id ?? null,
                'sql' => $query->sql,
                'bindings' => $query->bindings,
                'time' => $query->time,
            ]);
        }
    });
}

Gunakan EXPLAIN untuk analyze query plan dan pastikan index tenant_id selalu digunakan.

Backup dan Disaster Recovery Strategy

Dalam shared database multitenancy, backup harus bisa restore data per tenant jika ada incident.

Strategi yang proven adalah kombinasi full backup harian dan logical backup per tenant.

// Script backup per tenant (MySQL)
mysqldump -u root -p database_name \
  --where="tenant_id=123" \
  users posts comments \
  > tenant_123_backup.sql

Untuk PostgreSQL, gunakan pg_dump dengan WHERE clause similar.

Simpan backup di S3 atau object storage dengan naming convention yang include tenant_id dan timestamp.

Handling Tenant Onboarding dan Provisioning

Proses onboarding tenant baru harus smooth dan automated.

Buat seeder yang setup data awal untuk tenant baru—default roles, permissions, sample data.

// app/Services/TenantProvisioningService.php
class TenantProvisioningService
{
    public function provision(Tenant $tenant)
    {
        // Set tenant context
        app()->instance('tenant', $tenant);
        
        DB::transaction(function() use ($tenant) {
            // Create default roles
            $this->createDefaultRoles();
            
            // Create admin user
            $admin = User::create([
                'tenant_id' => $tenant->id,
                'name' => $tenant->owner_name,
                'email' => $tenant->owner_email,
                'password' => bcrypt($tenant->temp_password),
            ]);
            
            $admin->assignRole('admin');
            
            // Setup default settings
            $tenant->setSetting('onboarding_completed', false);
            
            // Send welcome email
            Mail::to($admin)->send(new WelcomeEmail($tenant));
        });
    }
}

Security Best Practices untuk Multitenancy

Security adalah concern terbesar di multitenancy—satu vulnerability bisa expose data semua tenant.

Implement beberapa layer defense ini:

• Validasi tenant_id di middleware level, bukan hanya model level
• Audit log untuk semua aksi critical dengan tenant context
• Rate limiting per tenant untuk prevent abuse
• Regular security audit untuk query yang bypass tenant scope
• Encrypt sensitive data per tenant dengan tenant-specific encryption key

Jangan pernah expose tenant_id di URL atau form field yang bisa dimanipulasi user.

Selalu ambil tenant dari session atau JWT token yang sudah terverifikasi.

Monitoring dan Observability

Setup monitoring yang track metrics per tenant, bukan aggregate.

Metrics penting yang perlu dimonitor:

• Query count dan average response time per tenant
• Storage usage per tenant
• API rate limit hits per tenant
• Error rate per tenant
• Active users per tenant per hari

Gunakan tools seperti Laravel Telescope dengan tenant filtering untuk debugging.

// config/telescope.php
'watchers' => [
    Watchers\QueryWatcher::class => [
        'enabled' => env('TELESCOPE_QUERY_WATCHER', true),
        'slow' => 100,
        'ignore_packages' => true,
    ],
],

// Tag dengan tenant_id
Telescope::tag(function () {
    return app()->has('tenant') 
        ? ['tenant:' . app('tenant')->id]
        : [];
});

Scaling Strategy untuk Growth

Saat jumlah tenant bertambah, pertimbangkan strategi scaling ini:

Vertical Scaling: Upgrade database server specs—ini solusi termudah untuk short-term.

Read Replica: Setup read replica untuk query heavy tenant, redirect read query ke replica.

Database Sharding: Partisi tenant ke multiple database berdasarkan tenant_id range atau geographic region.

Tenant Tiering: Pisahkan high-value tenant ke dedicated database, sisanya di shared database.

Untuk SaaS B2B Indonesia, mulai dengan shared database, setup monitoring yang baik, dan migrate ke dedicated resources hanya untuk tenant yang benar-benar membutuhkan.

Kesimpulan

Membangun multitenancy architecture yang proper adalah kunci sukses SaaS B2B di Indonesia.

Mulai dengan row-level multitenancy menggunakan global scope untuk simplicity, tambahkan layer caching dan monitoring yang baik, dan pastikan security di setiap layer.

Jangan over-engineer di awal—pilih arsitektur yang sesuai dengan scale saat ini, tapi design dengan mindset untuk easy migration ke approach yang lebih isolated jika diperlukan.

Yang terpenting adalah konsistensi dalam enforce tenant isolation di semua query dan operation, plus testing yang comprehensive untuk prevent data leakage.

Dengan foundation yang solid, aplikasi SaaS Anda siap scale untuk melayani ratusan hingga ribuan tenant B2B di Indonesia dengan performa dan security yang terjaga.