There are times I have to ask myself if I've really been in this industry for three years. For the longest time, I was always around tech, but mostly on the consumer side of it: games. Never the systems behind them.
That's part of why I switched from BSBA to BSIT in the first place. I loved tech, and I hated the theoretical, memorization-heavy grind of business subjects. Turns out programming isn't that different. There's plenty to memorize here too. The difference is that in programming, the memorizing is in service of something I actually find interesting.
The questions that caught me off guard
Recently, I got asked about multi-tenancy. My answer, roughly: "It's where you have multiple tenants, and you're the landlord. The tenants report to the landlord." Technically not wrong, but painfully thin. When the follow-up came, advantages and disadvantages, I had nothing solid to offer.
The frustrating part is that multi-tenancy wasn't a foreign concept to me. I've touched it before. Just not enough to explain it out loud, under pressure, in a way that showed I actually understood it rather than half-remembered it.
Then came the harder ones. What's a broker? What's a provider? I knew "provider," at least loosely, it's about dependencies and procurement, I think I said, but I couldn't get more specific than that. "Broker" was just a blank. And then: what's the difference between an API and a REST API? Honestly, I'd never sat down and separated those two ideas. We use the terms interchangeably at work. An API is something you consume, that's about as far as my mental model went. I didn't look up what REST actually stood for, or meant, until afterward.
Working through it afterward
Multi-tenancy was the real shock, because I know I've handled pieces of it before. Just not the whole picture, more like crumbs of the loaf than the loaf itself. There was no instant recall in the moment. But once I calmed down and sat with it, it clicked faster than I expected.
The landlord analogy actually holds up better than I gave it credit for in the moment. Think of a single apartment building versus a subdivision of standalone houses. In multi-tenancy, your tenants (the different customers or organizations using your app) share the same underlying resources, the "building": one codebase, one running application, and often one database, with each tenant's data logically separated (say, by a tenant_id column, or a separate schema per tenant). The landlord's advantage is exactly what I sensed but couldn't articulate: it's far easier to maintain, patch, and scale one building than to drive around a subdivision fixing each house individually. The tradeoff is the flip side of that same coin, tenants share resources, so a noisy neighbor (a tenant hammering the database, or a bug that leaks data across tenants) is a much bigger risk than it would be in a fully isolated, single-tenant setup.
Providers and brokers turned out to be less exotic than they felt in the moment.
A provider (in Laravel, a service provider) is close to what I fumbled toward: it's the bootstrapping layer. When the app boots, providers register the building blocks, database connections, config, third-party integrations, into the application's container, so that by the time your code runs, everything it depends on is already wired up and ready. It's less "procurement" and more "assembly line before the app opens for business."
A broker is a middleman, and my gut instinct there wasn't wrong, I just couldn't hold onto the definition under pressure. A broker sits between two parties that shouldn't have to know about each other directly. It takes a message from whoever's sending it and routes it to whoever's supposed to receive it, so the sender never has to know who's listening on the other end.
Here's the part that actually got to me: I've used Redis a lot. Queues, caching, pub/sub, it's been part of my stack for a while now. But I never sat down and connected "the thing I use all the time" to the word "broker." I was using the tool without ever naming what category it belonged to. RabbitMQ I'd only ever heard of in passing, never touched it. Kafka was the most foreign of the three, I couldn't have told you what it even did. So when I got asked about brokers, I wasn't drawing a blank because I lacked experience. I was drawing a blank because I'd never labeled the experience I already had.
Observers and dispatchers were a similar story, but the gap here made more sense once I sat with it. All I could offer in the moment was "it's kind of a worker that runs when there's a changing status." Not far off, but vague, because I genuinely didn't know an observer is usually tied to a database model: it listens for a model being created, updated, or deleted, and reacts without the original code needing to know it exists. Dispatchers made more sense to me instinctively, I understood them as "events happening," which is closer to the mark: a dispatcher sends a job, event, or message off to whatever's supposed to handle it.
Thinking about it afterward, I don't think this was a knowledge gap so much as an exposure gap. Observers and dispatchers earn their keep when multiple users or multiple services are interacting with each other, when there's actually something worth reacting to. My portfolio projects have never been that advanced. I'm the only user on most of them, so there's rarely a second actor whose action needs to trigger a reaction somewhere else. The one place I've genuinely touched this pattern is dispatching emails, and even that is a narrow slice of what these patterns are for. I sometimes wish I had a more advanced project sitting in my portfolio, something with real multi-user interaction, just so I'd have had the chance to bump into this stuff naturally instead of only meeting it by name for the first time when someone asked.
And the API versus REST API question, the one that felt almost embarrassing in hindsight. API is the broad umbrella: any defined way for two pieces of software to talk to each other. REST is one specific architectural style for building APIs, over HTTP, where you treat everything as a "resource" identified by a URL, and use standard verbs (GET, POST, PUT, DELETE) to act on it, stateless, one request at a time, no memory of what came before. So a REST API is a particular kind of API, not a synonym for it. Every REST API is an API. Not every API is REST.
What I'm taking from this
None of these concepts were truly foreign to me. That's the part that stings a little and also the part that makes me want to write this down. I'd brushed against every one of these ideas on the job. What I lacked wasn't exposure, it was the ability to turn "I've used this" into "I can explain this clearly to someone else." That gap between doing and explaining is apparently where three years of experience can still leave you exposed.
I'm treating this less as a failure and more as a checklist now: multi-tenancy, providers, brokers, observers, dispatchers, REST. Concepts I've used but never had to defend out loud. Worth fixing before the next time someone asks.