Investment Corporation Bangladesh Assistant Programmer Exam 27 June 2026 — Question Solution | ইনভেস্টমেন্ট কর্পোরেশন অব বাংলাদেশ (আইসিবি) সহকারী প্রোগ্রামার নিয়োগ পরীক্ষা ২০২৬ — প্রশ্ন সমাধান

Proposed solution: keep the system on premises but rebuild it as a horizontally scalable private cloud: a virtualised or containerised cluster in ISTCL's own (or another in-country) data centre, with load balancing, caching, database replication and asynchronous processing, introduced in phases after the real bottleneck has been measured.

Why: it gives cloud-style elasticity for an 8× rise (10,000 → 80,000 users) while every record stays inside the organisation's controlled, in-country facilities (data sovereignty), and it reuses existing servers and spreads spending over phases (budget).

Step 1: measure before buying

• Use APM and logs to find where peak-hour time is spent: application code, database queries, disk I/O or the network.
• Load-test a copy of the system at 20k, 40k and 80k simulated users to find the breaking point of each tier.
• Fix cheap problems first: missing indexes, slow queries, no connection pooling, oversized pages.

Step 2: the target architecture

flowchart LR
    U["Users (up to 80,000)"] --> LB["Load balancer pair (active/standby)"]
    LB --> A1["App node 1"]
    LB --> A2["App node 2"]
    LB --> AN["App node N (add on demand)"]
    A1 & A2 & AN --> C["In-memory cache (e.g. Redis)"]
    A1 & A2 & AN --> Q["Message queue (reports, notifications)"]
    C --> P["Primary DB (writes)"]
    A1 & A2 & AN --> R["Read replicas (reads)"]
    P -- "replication" --> R
    Q --> W["Background workers"]

Technique	What it fixes	Budget impact
Virtualisation or containers (e.g. VMware, Proxmox, Kubernetes) on existing servers	Runs many stateless app nodes; add nodes at peak	Reuses owned hardware; free options avoid licence fees
Load balancer + stateless app tier (sessions in cache)	Spreads traffic; no single overloaded server; failover	Low
In-memory cache	Serves repeated reads (prices, portfolios) in memory	Low; cuts DB load sharply
DB read replicas, partitioning, indexing, connection pooling	Removes the database bottleneck	Moderate
Message queue + workers	Moves slow jobs (reports, e-mails) out of the user's request	Low
Monitoring and auto-alerting	Detects saturation before users feel it	Low

Worked sizing (illustrative figures)

Assume each user sends one request every 10 s at peak.

• Peak load = 80,000 ÷ 10 = 8,000 requests/s.
• If a load test shows one app node serves 500 requests/s within the latency target: 8,000 ÷ 500 = 16 nodes, plus 2 spare for failover = 18 nodes.
• If 80% of requests are reads and the cache hit ratio is 90%, the database sees 8,000 × 0.8 × 0.1 = 640 reads/s + 8,000 × 0.2 = 1,600 writes/s = 2,240 requests/s, 72% less than 8,000.

Why not the alternatives

• Vertical scaling only (a bigger server): costly, has a hard ceiling and stays a single point of failure.
• Public cloud: ruled out by management because of budget and sovereignty. If the policy later allows, a hybrid model can burst non-sensitive, stateless work (e.g. static web content) to a provider inside Bangladesh while customer and transaction data stays on premises.

Phased rollout

1. Quick fixes from Step 1 (weeks).
2. Load balancer, stateless app nodes and cache.
3. Read replicas and queues.
4. Capacity planning each quarter against actual growth.

Exam tip: state both halves: the proposal (on-premises scale-out or private cloud, possibly hybrid) and why it satisfies all three constraints: performance at 8× load, budget, and data sovereignty.

Given: Server X handles 60% of the requests and Server Y the other 40%; the probability of high latency is 2% on Server X and 4% on Server Y.
To find: (a) the total probability of high latency; (b) the probability that a delayed request was handled by Server X.

Answer: P(high latency) = 0.028 (2.8%), and P(Server X | delayed) = 3/7 ≈ 0.4286 (42.86%).

Events and given data

• X = the request is handled by Server X, Y = handled by Server Y, L = the request has high latency.
• P(X) = 0.60, P(Y) = 0.40 (X and Y cover every request and do not overlap).
• P(L | X) = 0.02, P(L | Y) = 0.04.

Probability tree

flowchart LR
    R["Request"] -- "0.60" --> X["Server X"]
    R -- "0.40" --> Y["Server Y"]
    X -- "0.02" --> XL["X and delayed: 0.012"]
    X -- "0.98" --> XN["X and normal: 0.588"]
    Y -- "0.04" --> YL["Y and delayed: 0.016"]
    Y -- "0.96" --> YN["Y and normal: 0.384"]

(a) Total probability of high latency

By the theorem of total probability:

P(L) = P(X)·P(L | X) + P(Y)·P(L | Y)
= 0.60 × 0.02 + 0.40 × 0.04
= 0.012 + 0.016
= 0.028

So 2.8% of all requests face high latency.

(b) Probability that a delayed request came from Server X

By Bayes' theorem:

P(X | L) = P(X)·P(L | X) ÷ P(L)
= 0.012 ÷ 0.028
= 12/28 = 3/7 ≈ 0.4286

So about 42.86% of the delayed requests were served by Server X.

Check

• P(Y | L) = 0.016 ÷ 0.028 = 4/7 ≈ 0.5714, and 3/7 + 4/7 = 1 ✓.
• All four branch ends add up to 1: 0.012 + 0.588 + 0.016 + 0.384 = 1.000 ✓.
• Counting check with 10,000 requests: X serves 6,000, of which 120 are delayed; Y serves 4,000, of which 160 are delayed. Total delayed = 280 (2.8%), and 120/280 = 3/7 ✓.

Interpretation

Server X handles more traffic (60%) yet causes fewer of the delays (about 43%), because its own delay rate is half of Y's. Server Y is the weaker server: it carries 40% of the load but produces about 57% of the delayed requests, so it is the first candidate for tuning or for receiving a smaller share from the load balancer.

Exam tip: "total probability" is the weighted sum over all servers; "given that it was delayed, which server" is Bayes' theorem, where the total probability becomes the denominator.